Windows Confidential: Aliens Ate My Software
When space aliens hold up your product release and other creative answers for why your product is delayed.
One of my colleagues used to work for a company that manufactured hardware devices. He told me the release of a highly anticipated product was once held up by a bug in his part of the device driver. There appeared to be some sort of race condition that resulted in memory corruption. Bad things happen when you have memory corruption in a device driver.
The previous developer for that part of the driver was kind enough to leave an enigmatic comment in the code: “And then the space aliens come.” Senior management was naturally concerned about this one bug that was delaying the release of their product. They didn’t seem too concerned about the space aliens, just the fact that they were getting in the way of the product release.
As the senior managers weren’t the ones doing the bug investigating, they did what most senior managers do when they need something done—they kept bugging the person actually debugging the code. After all, everyone knows developers will debug problems faster if you pester them for status reports and pointedly lurk outside their office.
At some point, the senior managers decided to look for creative solutions to the problem instead of pestering the poor developer who was trying to get a handle on the elusive memory-corruption bug. They found one.
Their “solution” was to ramp up manufacturing, despite the absence of a fully debugged driver. The factories overseas were instructed to produce fully packaged boxes with their new devices, but with one little catch. The boxes wouldn’t include a floppy disk with the final driver (this being back in the days when device drivers came on floppy disks). Instead, there was a little slot in the top. The boxes of nearly finished products would then be loaded onto ships and transported across the sea.
It takes a few weeks for a transport ship to cross the ocean. The hope was that our hero the debugging developer would identify and fix the bug while the devices were still en route. If everything worked out, the floppy disks with the updated driver would be manufactured locally, loaded onto trucks and sent to meet the ship as it arrived on shore.
When the devices were unloaded from the ship, workers would open the crates, insert one floppy disk into each box via the slot on top, then seal the crates back up and send them off to wherever they needed to go. Fortunately, our hero developer did identify the bug. He was able to fix it in time, and the rest of the plan proceeded without further delay.
If you’re curious about the nature of the actual bug, here’s what happened. When the code fragment in question executed, the device sometimes triggered a hardware interrupt. The hardware interrupt handler had a bug that caused it to not restore the registers properly before returning control to the original code. From the point of view of the interrupted code, it was indeed as if space aliens had come and corrupted the registers in the CPU. So that original developer wasn’t far off.
I’ve been told of one computer manufacturer that once considered pulling off an even more extreme version of this trick when a new version of Windows was due for release. In order to get their computers to market quickly, their plan was to manufacture them with a copy of a prerelease build and load them onto ships.
Instead of merely meeting the ships as they arrived on shore, their idea was to intercept each cargo ship as it crossed the ocean, just like in spy movies. They would deploy a team of people who would open every computer box and upgrade the OS to the final release version of Windows right there on the ship.
I don’t know how seriously they considered this audacious plan, but it was ultimately abandoned. They decided to wait until the final version was released before packing the computers into boxes. That just gives you an idea of the lengths to which some will go to expedite getting their product out there on time.
Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. Don’t tell anyone, but you’re his favorite reader.