Windows ConfidentialWindows 95 Unplugged

Raymond Chen

Obwohl 32-Bit-Programme für Windows® 95 mit einem durchschnittlichen 32-Bit-Compiler und 16-Bit-Programme mit einem durchschnittlichen 16-Bit-Compiler gut beraten wären, benötigte Windows 95 selbst einen besonderen Compiler, und zwar einen, der sowohl mit 32-Bit- als auch mit 16-Bit-Programmen umgehen und diese Lücke überbrücken kann. Windows 95 benötigte außerdem einen benutzerdefinierten Linker, der diese zwei Arten von Code miteinander verknüpfen konnte, und es benötigte einen benutzerdefinierten Linker für VxDs (das Treiberformat für Windows 95).

Das Windows 95-Team war darauf angewiesen, dass die Sprach- und Toolabteilung diese speziellen Compiler und Linker bereitstellen. Ich bin mir sicher, dass sich die Sprachabteilung über diese Anfrage wunderte: „Wir sollen einen Compiler erstellen, der X, Y und Z ausführt, und er wird während seiner gesamten Lebensdauer nur zur Kompilierung von zwei DLLs eingesetzt?“ Richtig. Aber es handelte sich immerhin um zwei ziemlich wichtige DLLs.

Trotz der offensichtlichen Absurdität der Anfrage wurde sie von der Sprach- und Toolabteilung erfüllt, und der hochspezialisierte Compiler und Linker wurde in den Windows 95-Buildprozess aufgenommen. Selbstverständlich war der Compiler nicht von Anfang an fertig entwickelt. Das Windows-Team erhielt eine vorläufige Version und dann regelmäßige Updates, sobald neue Optimierungen implementiert und Fehler korrigiert wurden.

Eines Tages verlangsamte sich der Windows 95-Build unerwartet auf ein Schneckentempo. Eine Datei, die normalerweise in wenigen Sekunden verlinkt wurde, benötigte plötzlich Minuten. Die Datei wurde zwar erfolgreich generiert, aber das Ganze dauerte ewig. Davon war nicht nur der Computer eines einzigen Entwicklers betroffen. Das Problem trat bei allen im Team auf. War unser Code plötzlich auf einen pathologischen Fall im Linker gestoßen? Hatten wir zufällig einen Fehler im Linker entdeckt?

Nach einigem Debuggen stellten wir die Fehlerquelle fest. Die letzte Version des Linkers enthielt einen Diagnosecode, und den hatten die Kollegen aus der Sprachabteilung vergessen zu entfernen, bevor sie den Code dem Windows-Team übergaben. Dieser Diagnosecode protokollierte seine Ausgabe in einer Datei, die auf einem Computer im Büro eines der Mitglieder des Compilerteams gespeichert wurde. Zufällig war dieser Computer ausgeschaltet. (Das erinnert mich an Leslie Lamport und seinen berühmten Aphorismus, mit dem er ein verteiltes System als ein System beschreibt, in dem Sie keine Arbeit erledigen können, weil ein Ihnen völlig unbekannter Computer nicht eingeschaltet ist.)

Diese Version des Linkers war wochenlang völlig problemlos ausgeführt worden. Jedes Mal, wenn jemand versuchte, beim Erstellen von Windows 95 einen VxD zu verknüpfen, wurde die Datei auf dem Computer dieses Entwicklers aktualisiert. Solange dieser Computer eingeschaltet und mit dem Netzwerk verbunden war, hat niemand jemals etwas bemerkt. Aber eines Tages wurde dieser Computer ausgeschaltet, und alles verfiel in ein Schneckentempo.

Nachdem das Problem identifiziert war, dauerte es nicht lange, bis die Compilerleute dem Windows-Team einen Patch gaben, mit dem der Diagnosecode vom Linker entfernt wurde.

Es gibt verschiedene Pointen zu dieser Geschichte, je nachdem, wer sie erzählt. Wenn ich die Geschichte erzähle, ist die Pointe: „Und dieser Compilerentwickler kam später zum Windows-Team und wurde mein Chef.“ Ich habe diese Geschichte immer wieder gern erzählt, um jemanden damit zu necken.

Wenn aber mein Chef sie erzählt, ist die Pointe eine ganz andere: „Und es stellte sich heraus, dass ich diesen Diagnosecode nicht einmal geschrieben hatte. Es war einer meiner Kollegen, der entschieden hatte, dass er lieber meinen als seinen eigenen Computer mit Diagnoseinformationen füllt!“

Raymond Chen befasst sich auf seiner Website „The Old New Thing“ und in seinem gleichnamigen Buch mit der Geschichte von Windows und mit der Win32-Programmierung. Seine DNA ist voll von totem Code.