Microsoft-Entwickler enthüllt: So entstand das Windows 95-Setup-Design

Raymond Chen, der seit mehr als 30 Jahren bei Microsoft arbeitet, teilt in seinem Blog The Old New Thing gerne tiefgründige technische Anekdoten rund um die Entwicklung von Windows. Eines der am häufigsten diskutierten Themen ist die Frage, warum das Windows-95-Setup auf mehrere Betriebssysteme setzte, anstatt sich einfach auf MS-DOS zu verlassen. Hätte man das Installationsprogramm nicht auch in einer grafischen Umgebung innerhalb von MS-DOS realisieren können? Chens Antwort: Nein! In einem aktuellen Blog-Beitrag erklärt er ausführlich, warum das eine schlechte Idee gewesen wäre.
MS-DOS konnte zwar Grafik – aber nicht wirklich gut
Erstmal vorab: Ja, MS-DOS konnte Grafikmodi verwenden. Das heißt aber nicht, dass es für ein grafisches Installationsprogramm geeignet gewesen wäre. Das Betriebssystem selbst bot keine fortgeschrittenen Grafikfunktionen. Die einzige systemeigene Möglichkeit, Grafiken darzustellen, war eine BIOS-Funktion zum Setzen einzelner Pixel – was eine extrem langwierige Lösung gewesen wäre.
Wer mehr Leistung wollte, musste direkt auf den Grafikspeicher zugreifen und eine eigene Grafikbibliothek schreiben. Immerhin setzte Windows 95 mindestens eine VGA-Grafikkarte voraus, sodass man sich wenigstens nicht mit den älteren CGA- oder EGA-Modi herumschlagen musste. Aber auch mit VGA hätte man eine komplette Zeichenbibliothek, Fensterverwaltung und Eingabemethoden neu entwickeln müssen.
Ein neues Betriebssystem nur für die Installation?
Neben der Grafik musste das Setup-Programm auch Dialogboxen unterstützen – mit Schaltflächen, Eingabefeldern und Tastatursteuerung. Die Entwicklung eines eigenen UI-Frameworks für all diese Funktionen hätte jedoch enorme Ressourcen verschlungen. Außerdem musste das Setup-Programm mit nicht-alphabetischen Zeichensätzen wie zum Beispiel im Japanischen umgehen können. Die Windows-Entwickler:innen hätten also mit den Teams in Tokio zusammenarbeiten müssen, was aufgrund der Zeitverschiebung zusätzliche Herausforderungen mit sich gebracht hätte.
Doch damit nicht genug: Das Setup benötigte einen Timer für Animationen, eine Speicherverwaltung für größere Datenmengen, die weit über die 640 KB von MS-DOS hinausgingen. Und auch eine geschützte Speicherverwaltung wäre nötig gewesen – also im Grunde ein sogenannter MS-DOS-Extender. Kurz gesagt: Um ein grafisches Setup-Programm unter MS-DOS zu entwickeln, hätte Microsoft praktisch ein Mini-Betriebssystem entwickeln müssen, das nichts anderes tut, als Windows 95 zu installieren.
Die bessere Lösung: Windows 3.1 Runtime
Aber warum das Rad neu erfinden? Wie Chen erklärt, hatte Microsoft schon ein vollwertiges Betriebssystem mit allen notwendigen Funktionen – nämlich Windows 3.1. Es verfügte über Grafiktreiber, eine stabile GUI-Umgebung, Eingabemethoden für internationale Sprachen, Speicherverwaltung und ein Event-System. Die Entscheidung, auf Windows 3.1 Runtime zu setzen, war also eine logische und effiziente Lösung, die sicherstellte, dass das Setup-Programm stabil und leistungsstark lief.
Interessanterweise verfolgt Windows auch heute noch eine ähnliche Strategie: Aktuelle Windows-Versionen setzen bei der Installation auf das sogenannte Windows Preinstallation Environment (Windows PE). Dabei handelt es sich um eine abgespeckte Version des eigentlichen Betriebssystems, die speziell für den Installationsvorgang entwickelt wurde. Das Grundprinzip bleibt dabei erhalten: Anstatt ein eigenes Mini-Betriebssystem für die Installation zu entwickeln, greift Microsoft auf eine erprobte und optimierte Lösung zurück. Wie Raymond Chen verdeutlicht, beruhen viele Designentscheidungen in der Softwareentwicklung auf Effizienz, Stabilität und pragmatischen Überlegungen – selbst, wenn sie zunächst ungewöhnlich erscheinen.
5 praktische Tipps und Tricks für die Arbeit mit Excel