Browsed by
Category: Programming

Blue-screen Windows on purpose

Blue-screen Windows on purpose

I wrote awhile back on how to crash Linux/cause a Linux kernel panic in order to test how your program can handle a crash – but can you cause a Windows blue-screen programmatically?

Raymond Chen of the New Old Thing describes a variety of methods to crash Windows purposefully. He also cautions against ad-hoc methods like killing winlogin.

Methods you can use to cause a Windows Blue-screen:

  1. Windows allows you to configure a specific keyboard combination to cause a crash. You set some registry keys and then can crash a system by holding right CTRL then pressing scroll lock key twice. You can also customize the key sequence via registering custom keyboard scan codes. If you have a kernel debugger attached it will trigger the kernel debugger after the crash dump is written.
  2. The best way to trigger an artificial kernel crash is to use NotMyFault, which is part of the Microsoft Windows SysInternals tools.
Demo scenes are not dead

Demo scenes are not dead

Massive in the 90’s, Demoscenes are not dead. Revision 2024 demo party just took place March 29th to April 1st in Saarbrücken Germany.

There was music, seminars, videos, livestreams, a 5k run, and of course – amazing code demos. This included some competing 256-byte demos here. One of the best was a post-apocalyptic black-and-white city created with just 256 bytes of Gopher code running on DOS.

Admitting your mistakes

Admitting your mistakes

Speaking at QCon back in 2009, Tony Hoare admitted to probably one of the biggest mistakes of his career – one that every programmer knows all too well. The invention of NULL because ‘it was so easy to implement’.

I call it my billion-dollar mistake. It was the invention of the null reference in 1965.

At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Reading 50 year old rope core memory

Reading 50 year old rope core memory

Mike Steward decided to recover the original Apollo guidance computer programs that landed man on the Moon in the 1960’s. Unfortunately some of them seem to have been lost to history.

It turns out, chunks of the original hardware still exist – such as the rope core memory which contained the programs. The next question is, how do you read these programs off 50 year old rope core memory hardware? This video below tells you how he did it!

He even wrote a web app that simulates how core memory works. We do a decent job recording history’s events, but I think it’s extremely cool that this kind of historical technical information is not being lost to the ages.

You can also check out the many other videos about the Apollo guidance computer in the other parts of his videos – or a previous article which has a super-awesome description of how Apollo computers work by Robert Wills.

Perfect code vs perfect products

Perfect code vs perfect products

For one-shot things like games – focus on the experience above all else.

Update 2024/01: More proof that technical limits have little impact for making great games. Slay the Spire’s graphical glitches were there because the author only had two $70 monitors that were so bad he literally didn’t see the issues.

Maze-solving mice

Maze-solving mice

Veritasium does a great overview of maze-solving robots. He goes over the different algorithms as well as optimizations that weren’t optimal, but were faster because the mechanics of the path made it faster for the physics of the robots. There were also unique optimizations that take advantage of diagonals, gyroscopes, suction to make 6G turns, and other ideas.

It’s a reminder that even when something seems solved, there is likely huge optimizations still waiting to be discovered.

But then again, you can go the other direction and try to build the most unskilled robot. Hebocon celebrates unskilled robot builders – even penalizing those who try too hard or using proper technology.

Write your own NES emulator

Write your own NES emulator


“There is almost no reason to re-write a huge software codebase from scratch. If anything, evaluate wrapping it with an emulator that can filter for the things you want to change before a re-write.”

-Me (inspired by Joel Spolsky)

javidx9 walks us through his 3 month adventure writing a NES emulator in C++. He does a great job walking through the topics with beginner friendly explanations and good production values of diagrams and coding.

Other resources: