Share via

Windows ConfidentialWindows 95 Unplugged

Raymond Chen

Although 32-bit programs for Windows® 95 could use your average 32-bit compiler, and 16-bit programs could use your average 16-bit compiler, Windows 95 itself needed a special compiler, one that understood both the 32-bit and 16-bit worlds and could bridge that gap. Windows 95 also needed a custom linker that understood how to glue these two types of code together, and it needed a custom linker for VxDs (the driver format for Windows 95).

The Windows 95 team relied on the languages and tools division to provide these special-purpose compilers and linkers. I'm sure the languages division found this to be a strange request: "You want us to write a compiler that does X, Y, and Z, and it's going to be used to compile only two DLLs in its entire lifetime?" It's true. But these were, after all, two pretty important DLLs.

Despite the apparent absurdity of the request, the languages and tools division came through, and the highly specialized compiler and linker became part of the Windows 95 build process. Of course, the compiler wasn't fully formed out of the gate. The Windows team received a preliminary version, and then periodic updates as new optimizations were implemented and bugs were fixed.

One day the Windows 95 build unexpectedly slowed to a crawl. A file that used to take a few seconds to link suddenly took minutes. The file was still generated successfully, but it took forever. And this wasn't on just one developer's machine—the problem hit everybody across the entire team. Did our code suddenly hit some pathological case in the linker? Did we stumble across a linker bug?

After some debugging, we identified the source of the problem. The most recent version of the linker contained some diagnostic code that the languages folks forgot to remove before handing the code off to the Windows team. This diagnostic code logged its output to a file that was stored on a computer sitting in the office of a member of the compiler team. And the computer happened to be turned off. (This brings to mind Leslie Lamport, who famously described a distributed system as one in which you can't get any work done because a computer you never heard of is down.)


That version of the linker had been running happily for weeks. Every time anybody tried to link a VxD when building Windows 95, an update was made to the file sitting on that developer's computer. As long as that computer remained turned on and connected to the network, nobody ever noticed. But one day that computer was turned off, and everything slowed to a crawl.

Once the problem was identified, it didn't take very long for the compiler folks to give the Windows team a patch that removed the diagnostic code from the linker.

There are different punch lines to this story depending on who tells it. When I tell the story, the punch line is, "And that compiler developer later transferred to the Windows team and ended up being my boss." I've often enjoyed retelling this story as a form of gentle teasing.

However, if my boss tells the story, the punch line is very different: "And it turns out, I didn't even write that diagnostic code. It was one of my colleagues, who decided that instead of filling up his own computer with diagnostic information, he'd fill mine!"

Raymond Chen's Web site, The Old New Thing, and identically titled book deal with Windows history and Win32 programming. His DNA is filled with dead code.