Im Oktober 2026 bestätigte das Fachportal Windows Latest eine erstaunliche Tatsache: Tief im modernen Windows 11 26H2 schlummert noch immer originaler Quellcode der Speicherverwaltung von Windows 95 aus dem Jahr 1995. Dieser Code wurde keineswegs entfernt, sondern von Microsoft neu kompiliert und in die Kompatibilitätsschicht des Betriebssystems integriert. Seine einzige Aufgabe besteht darin, drei Jahrzehnte alte Programme zu stützen, deren Entwickler damals Fehler bei der Speicherverwaltung machten.
Abwärtskompatibilität bedeutet bei Microsoft mitunter eine dauerhaft konservierte Kopie historischen Quellcodes. Indem das Unternehmen alte Module unverändert in moderne Systeme einbettet, werden einstige Programmfehler quasi zu unumstößlichen Systemverträgen erhoben. Jeder PC, auf dem heute Windows 11 läuft, zahlt somit weiterhin den Preis für kommerzielle Kompromisse von vor über dreißig Jahren.
Im Windows-11-Werkzeugkasten: Lebendiger Code aus Windows 95
Um dieses lebende Fossil in Windows 11 26H2 aufzuspüren, sind keine tiefen Hacking-Kenntnisse erforderlich. Es genügt, das offizielle Windows ADK von Microsoft zu installieren, die Option „Application Compatibility Tools“ auszuwählen und den 32-Bit Compatibility Administrator zu starten. In der riesigen Liste der System-Fixes taucht prompt ein Eintrag namens EmulateHeap auf.
Abb.: Die EmulateHeap-Kompatibilitätsoption im Compatibility Administrator von Windows 11. Quelle: Windows Latest
Die Funktionsweise von EmulateHeap ist direkt und pragmatisch: Wird diese Option für eine ältere Anwendung aktiviert, fängt das Betriebssystem sämtliche Heap-Speicheraufrufe des Programms ab. Von Speicherallokationen über HeapCreate bis hin zu Sperroperationen mittels LocalLock und Neuzuweisungen per GlobalReAlloc werden alle Instruktionen auf eine spezielle Implementierung umgeleitet. Dieses Modul verhält sich exakt so wie das 1995 veröffentlichte Windows 95.
Microsoft entschied sich dabei ganz bewusst dagegen, das historische Verhalten über moderne Heuristiken lediglich nachzuahmen. Laut Aufzeichnungen des langjährigen Microsoft-Ingenieurs Raymond Chen griff das Team direkt auf den ursprünglichen Quellcode des Windows-95-Heap-Managers zurück, kompilierte ihn neu und verpackte ihn in das Kompatibilitätsmodul. Microsoft verzichtete auf komplexe Verhaltenssimulationen und wählte den Originalcode, um subtile Inkompatibilitätsrisiken von vornherein auszuschließen. So erhielten 31 Jahre alte Maschineninstruktionen ein dauerhaftes Bleiberecht im modernsten Windows.
Die Rettung von SimCity: Als Microsoft fremde Programmierfehler übernahm
Dieser scheinbar kuriose Patch hat seinen Ursprung in einem entscheidenden wirtschaftlichen Kräftemessen vor dreißig Jahren. Im Vorfeld der Veröffentlichung von Windows 95 stürzte der damalige PC-Megahit SimCity auf Testrechnern wiederholt ab. Hätte das neue Betriebssystem das wichtigste Vorzeigespiel der Ära nicht ausführen können, hätten die Anwender die Schuld unweigerlich beim Betriebssystem gesucht und nicht beim Spiel.
Abb.: Das damals weltweit gefeierte Städtebauspiel SimCity 2000. Quelle: Nap’n’Retrogaming
Nachforschungen der Microsoft-Ingenieure ergaben schnell, dass der Absturz vollkommen auf das Spiel selbst zurückzuführen war. Jon Ross, einer der Entwickler von SimCity, räumte später öffentlich ein, dass das Programm einen klassischen „Use-After-Free“-Fehler enthielt: Das Spiel gab Speicherbereiche an das Betriebssystem zurück, griff danach aber weiterhin ungehemmt auf die darin verbliebenen Daten zu.
Unter Windows 3.x blieb dieser schwere Fehler dank des primitiven Speichermodells verborgen. Das 16-Bit-System setzte auf kooperatives Multitasking; gab eine Anwendung Speicher frei, löschte oder reallozierte das System diese physischen Adressen nicht umgehend. Die alten Daten blieben unberührt an Ort und Stelle liegen, und das Spiel lief zufällig problemlos weiter. Windows 95 führte jedoch präemptives Multitasking und einen echten 32-Bit-Heap-Manager ein. Freigegebener Speicher wurde sofort überschrieben oder als ungültig markiert, was das Spiel augenblicklich zum Absturz brachte.
Der frühere Microsoft-Programm-Manager Joel Spolsky schilderte die Hintergründe im Jahr 2000 in einem berühmten Essay: Statt vom Spieleentwickler Maxis einen Notfall-Patch zu fordern, baute Microsoft eine Erkennungslogik direkt in die Speicherverwaltung von Windows 95 ein. Erkannte der Kernel, dass gerade SimCity lief, wechselte der Speichermanager in einen speziellen Modus, der freigegebenen Speicher nicht sofort recycelte. Um den Markterfolg und einen reibungslosen Übergang zu sichern, übernahm das Betriebssystem kurzerhand die Verantwortung für den fehlerhaften Fremdcode.
Wenn Sicherheitslücken zum Systemvertrag werden: Vom Patch zum permanenten Modul
Mitte der 1990er-Jahre waren solche Programmierfehler allgegenwärtig. Der PC-Softwaremarkt explodierte förmlich, und unzählige hastig gestrickte 32-Bit-Programme mit abenteuerlichen Fehlern drängten auf den Markt. Viele Programmierer gewöhnten sich an das nachsichtige Verhalten von Windows 95 und hielten die Möglichkeit, auf freigegebenen Speicher zuzugreifen, fälschlicherweise für ein garantiertes Systemfeature.
Als die Windows-NT-Architektur die 9x-Produktlinie vollständig ablöste, führte Microsoft einen wesentlich strikteren und sichereren Unternehmens-Heap ein. Das führte dazu, dass hunderte ältere Spiele und branchenspezifische Spezialprogramme auf modernen Systemen den Dienst versagten. Da Microsoft unmöglich für tausende Altanwendungen jeweils eigene Ausnahmebedingungen in den NT-Kernel schreiben konnte, stand das Team vor einer Grundsatzentscheidung: Sollte man die architektonische Reinheit wahren oder das gigantische Software-Ökosystem retten? Man entschied sich für einen pragmatischen Mittelweg.
Abb.: Der Überlebenspfad des Windows-95-Heap-Codes in der modernen Kompatibilitätsschicht. Quelle: Windows Latest
Die Ingenieure isolierten die Heap-Management-Komponenten vollständig aus dem Quellcodebaum von Windows 95 und bündelten sie als eigenständigen Kompatibilitäts-Fix namens EmulateHeap. Aus IT-Sicherheitssicht stellen Use-After-Free-Schwachstellen erhebliche Risiken dar, die bis zur Ausführung von beliebigem Schadcode führen können. Doch angesichts der harten Marktgesetze im Desktop-Geschäft wog Abwärtskompatibilität schwerer als architektonische Lehrbuchprinzipien. Microsoft erhob die historischen Softwaremängel damit dauerhaft zum verbindlichen Systemvertrag.
Moderne UI-Frameworks an der Oberfläche, Module von 1995 im Fundament
Dieses unbedingte Festhalten an der Kompatibilität erzeugt bemerkenswerte technische Gegensätze. An der Oberfläche modernisiert Microsoft Windows mit Hochdruck: Selbst jahrzehntealte Datei-Eigenschaftsfenster werden sukzessive auf das moderne WinUI-3-Framework umgestellt. Um Speichersicherheitslücken systematisch zu schließen, hält zudem die Programmiersprache Rust Einzug in den Windows-Kernel.
Doch hinter dieser modernen Fassade wird der historische Ballast unverändert mitgeschleppt. Selbst im Jahr 2026, in Windows 11 Build 26H2, nutzt Microsoft modernste Build-Pipelines, um 31 Jahre alten Quellcode aus Windows 95 zu kompilieren und in den offiziellen Installationsabbildern auszuliefern. Im krassen Gegensatz dazu wurde das einst überaus beliebte Standardspiel 3D Pinball vor Jahren kurzerhand gestrichen.
Der Grund für das Aus von 3D Pinball beim Übergang zu 64-Bit-Systemen war denkbar pragmatisch: Der Code für die Kollisionserkennung war komplett in 32-Bit-x86-Assembler verfasst, und jegliche Dokumentation zur Fließkommalogik fehlte. Bei der 64-Bit-Portierung flog die Kugel regelmäßig durch die Flipperarme hindurch. Weil die Fehlersuche Tage gedauert hätte, trennte sich Microsoft kurzerhand von dem Spiel. Die Nachsicht von Microsoft gegenüber altem Code hat klare Grenzen: Unterhaltungsprogramme sind jederzeit verzichtbar, das Fundament der Abwärtskompatibilität hingegen bleibt unantastbar.
Drei Jahrzehnte der Kompromisse: Der Preis moderner Hardware
Doch der jahrzehntelange Schutz historischer Altlasten stößt auf zeitgemäßer Hardware zunehmend an physikalische Grenzen. Seit Windows 11 22H2 häufen sich die Berichte von Retro-Gaming-Enthusiasten, wonach EmulateHeap immer unzuverlässiger arbeitet. Wer Klassiker wie Grand Theft Auto: Vice City oder Need for Speed: Most Wanted über diesen Kompatibilitätsmodus startet, erlebt häufig Tonausfälle oder sofortige Abstürze beim Start.
Die Ursache liegt darin, dass moderne PCs die technischen Annahmen des Jahres 1995 längst hinter sich gelassen haben. Heutige Systeme arbeiten mit Multi-Core-Prozessoren, komplexer Out-of-Order-Befehlsausführung und strikter Hardware-Speicherisolation. Der Heap-Manager von Windows 95 wurde für eine Single-Core-Ära mit flachem Speicherlayout geschrieben; mit modernen Mehrkernumgebungen und hochgradig parallelisierten Treibern kann er schlicht nicht mehr zuverlässig kooperieren.
Die grenzenlose Abwärtskompatibilität schuf das beispiellose Monopol von Windows, brachte aber auch immense technische Schulden mit sich. Mit jedem Entwicklungsschritt schleppt Microsoft den gesamten Ballast der Vergangenheit weiter mit. Was vor dreißig Jahren als provisorischer Patch begann, ist heute ein unverrückbares Code-Fossil. Wenn die Technologie zu weit voranschreitet, wird das unendliche Entgegenkommen gegenüber der Vergangenheit unweigerlich zur Bürde für jeden modernen Anwender.
Weiterführende Quellen:
- Bericht von Windows Latest: Warum Windows 11 noch immer den Speichermanager von Windows 95 enthält
- Joel on Software: Strategy Letter II: Chicken and Egg Problems
- Microsoft Technische Dokumentation: Windows Compatibility zur Funktionsweise von EmulateHeap
