Über die Jahre hat sich bei mir eine kleine Sammlung virtueller Maschinen angesammelt, auf denen Betriebssysteme aus mehreren Jahrzehnten Computergeschichte laufen. Von MS-DOS über Windows 3.1, 95, 98, Me, 2000, XP, Vista, 7 und 8.1 bis hin zu IBM OS/2 ist so ziemlich alles vertreten. Einige dieser Installationen begleiten mich schon seit vielen Jahren, mitsamt der Programme, Spiele und kleinen Hilfswerkzeuge, die ich damals tatsächlich verwendet habe.

Kürzlich habe ich mir wieder etwas Zeit genommen, um diese alten Systeme in VMware Workstation zu erkunden. Allerdings fiel das Erlebnis zunächst deutlich ernüchternder aus als erwartet.

Selbst vergleichsweise genügsame Betriebssysteme reagierten auffallend träge. Einfache Aktionen auf dem Desktop dauerten unnötig lange, die Wiedergabe von Multimedia-Inhalten lief alles andere als flüssig und insgesamt fühlte sich das Ganze erstaunlich ineffizient an. Schließlich reden wir hier von Software aus den Neunzigerjahren, die auf einer heutigen Workstation ausgeführt wird.

An Windows 98 sollte ein moderner Rechner doch nun wirklich nicht scheitern.

Der Übeltäter: VMwares ULM-Modus

Wie sich herausstellte, lag das Problem weder an Windows 98 noch an der emulierten Hardware oder am Alter von VMware. Verantwortlich war ausgerechnet Windows selbst, genauer gesagt der Hyper-V-Hypervisor.

Aktuelle Versionen von VMware Workstation können parallel zu Microsofts Hyper-V und verschiedenen virtualisierungsbasierten Sicherheitsfunktionen betrieben werden. Dazu verwendet VMware die Schnittstellen der Windows Hypervisor Platform (WHP).

Für die Kompatibilität ist das ausgesprochen praktisch. Allerdings hat diese Flexibilität ihren Preis.

Traditionell verwendet VMware einen eigenen Virtual Machine Monitor, der direkt auf die Virtualisierungsfunktionen des Prozessors zugreifen kann. Ist Hyper-V aktiv, kann VMware stattdessen in den sogenannten User Level Monitor (ULM) wechseln und die Virtualisierung über Microsofts Hypervisor-Schnittstellen abwickeln.

In meinem Fall hatte dieser Unterschied erhebliche Auswirkungen.

Welcher Modus tatsächlich verwendet wird, lässt sich anhand der Datei vmware.log im Verzeichnis der jeweiligen virtuellen Maschine feststellen. Dort findet sich beispielsweise folgender Eintrag:

Monitor Mode: ULM

Genau das war bei mir der Fall.

Anstelle des nativen VMware-Monitors liefen sämtliche virtuellen Maschinen über die zusätzliche Kompatibilitätsschicht von Hyper-V. Und offenbar war diese Konstellation für meine historischen Systeme alles andere als optimal.

Zurück zur nativen Virtualisierung

Da ich Hyper-V auf dieser Workstation ohnehin nicht benötige, habe ich den Windows-Hypervisor über die Windows-Features deaktiviert.

Nach einem Neustart konnte VMware endlich wieder seinen eigenen Virtualisierungsmonitor verwenden.

Im Protokoll stand nun:

Monitor Mode: CPL0

Der Unterschied war verblüffend.

Die alten Windows-Systeme reagierten plötzlich erheblich schneller. Die Bedienung des Desktops fühlte sich wieder unmittelbar an, Multimedia-Inhalte liefen deutlich flüssiger und selbst Anwendungen, die zuvor quälend langsam gewesen waren, ließen sich wieder angenehm benutzen.

Eigentlich eine ziemlich absurde Situation: Dreißig Jahre alte Software geriet auf einem modernen Rechner ins Stocken. Nicht etwa, weil dessen Rechenleistung nicht ausgereicht hätte, sondern weil die dazwischenliegende Virtualisierungsinfrastruktur unnötig ausbremste.

Ein wichtiger Hinweis für alle, die das selbst ausprobieren möchten: Je nach Konfiguration können neben Hyper-V auch die Windows-Features „Plattform für virtuelle Computer“, „Windows-Hypervisor-Plattform“, die Speicherintegrität, Windows Sandbox und weitere Funktionen der virtualisierungsbasierten Sicherheit (VBS) relevant sein. Wer den Hypervisor deaktiviert, beeinflusst damit unter anderem WSL2, Hyper-V-basierte Anwendungen und möglicherweise wichtige Sicherheitsmechanismen von Windows. Es handelt sich also um eine bewusste Abwägung und keineswegs um eine allgemeingültige Performanceoptimierung.

(Ja, diesen Screenshot habe ich tatsächlich heute Abend aufgenommen. Die erste Website des World Wide Web ist nach wie vor erreichbar und funktioniert sogar im Internet Explorer 4.0 SP1 unter Windows NT 4.0 Workstation mit Service Pack 6.)

Eine kleine Zeitreise durch die Windows-Geschichte

Nachdem das Performanceproblem behoben war, habe ich schließlich deutlich mehr Zeit mit meinen alten Systemen verbracht als ursprünglich vorgesehen.

Es hat einfach einen besonderen Reiz, Windows 3.1 zu starten und darin Office 4.3c vorzufinden, einschließlich all der Bedienkonzepte und gestalterischen Eigenheiten aus den Anfangsjahren grafischer Benutzeroberflächen.

Oder Windows 95 hochzufahren und anschließend Office 95 zu öffnen. Danach Windows 98 mit Office 97, Windows 2000 mit Office 2000, Windows XP mit Office 2007, Vista mit Office 2010 und so weiter.

Meine Sammlung bildet inzwischen einen beachtlichen Teil der Microsoft-Desktopgeschichte ab.

Und natürlich beschränkt sich das nicht auf Windows und Office.

Dazu kommen historische Versionen diverser Adobe-Programme, Winamp, VLC, Netscape, Microsoft Encarta, Works, Bob, der berüchtigte Office-Assistent Karl Klammer, umfangreiche Clipart-Sammlungen sowie Hunderte Spiele und kleinere Hilfsprogramme.

Sogar Flash Player 32 ist in einer der historischen Umgebungen noch installiert. Wirklich benötigen tue ich ihn allerdings nur selten. Die meisten Flash-Spiele funktionieren heutzutage mit Ruffle auch in meiner eigenen Webanwendung ziemlich gut.

Einige dieser Installationen enthalten jahrelang gewachsene Softwarebestände und zahlreiche Konfigurationsänderungen aus ihrer ursprünglichen Nutzungszeit. Es handelt sich also keineswegs nur um frisch installierte Windows-Versionen, die eigens für ein paar nostalgische Screenshots eingerichtet wurden.

Gerade das macht sie so interessant. Man betrachtet nicht einfach ein historisches Betriebssystem, sondern erlebt gewissermaßen eine Momentaufnahme davon, wie Computer damals tatsächlich genutzt wurden.

Mit einer ordentlich funktionierenden VMware-Umgebung lassen sich viele dieser Systeme auch heute noch erstaunlich gut bedienen.

Natürlich bedeutet das nicht, dass jedes historische Spiel und jede alte Grafikschnittstelle problemlos funktioniert. Insbesondere die zuverlässige 3D-Beschleunigung unter älteren Windows-Versionen bleibt eine Herausforderung. Für klassische Desktopanwendungen, Multimedia, Bürosoftware und zahlreiche ältere Spiele ist das Nutzungserlebnis allerdings überraschend angenehm.

Selbst Windows 7 und 8.1 sind inzwischen interessante Kandidaten für einen solchen Ausflug in die Vergangenheit. Während meiner Experimente reagierten sogar noch Teile ihrer historischen Windows-Update-Infrastruktur, einschließlich einzelner Aktivitäten rund um ältere Updates. Mit einer aktuellen Sicherheitsversorgung hat das selbstverständlich nichts mehr zu tun. Bemerkenswert ist es trotzdem.

Warum ich mir QEMU als VMware-Ersatz wünsche

Bei dieser Gelegenheit wurde mir allerdings auch eine alte Unzufriedenheit wieder bewusst.

Für die langfristige Erhaltung solcher Systeme wäre mir eine vollständig quelloffene Lösung wesentlich lieber.

QEMU ist zweifellos ein außergewöhnliches Projekt. Es ermöglicht die Emulation vollständiger Rechnerarchitekturen, unterstützt eine enorme Vielfalt virtueller Hardware und gehört zu den wichtigsten technologischen Grundlagen moderner Virtualisierung.

Doch ein historisches Windows-System zu betreiben, bedeutet eben mehr, als nur dessen Kernel erfolgreich zu starten.

Man benötigt passende Grafiktreiber, eine flüssige Bildschirmausgabe, funktionierenden Ton, eine komfortable Eingabesteuerung, zuverlässige virtuelle Hardware und idealerweise zumindest eine gewisse Form der Grafikbeschleunigung.

Genau hier besitzt VMware Workstation dank seiner jahrzehntelangen Entwicklung im Bereich der Desktopvirtualisierung und der Unterstützung älterer Gastsysteme noch immer einen bemerkenswerten Vorsprung.

Dabei gibt es durchaus gute QEMU-basierte Lösungen für ältere Windows-Versionen. Die Community hat unter anderem eigene Grafiktreiber und softwarebasierte Implementierungen der 3D-Beschleunigung entwickelt. Projekte wie SoftGPU und VMDisp9x leisten auf diesem Gebiet beeindruckende Arbeit.

Dennoch bleibt das Gesamtbild deutlich fragmentierter, gerade im Vergleich zu einer sauber konfigurierten VMware-VM mit den passenden historischen VMware Tools. Ältere Windows-Versionen laufen durchaus unter QEMU, aber mir ist es bislang nie gelungen, sämtliche Komponenten einschließlich erweiterter Grafikfunktionen, Audio und Netzwerk gleichermaßen zuverlässig zum Laufen zu bringen.

Das ist schade. Schließlich sollte die langfristige Bewahrung digitaler Computergeschichte möglichst wenig davon abhängen, ob proprietäre Software weiterhin verfügbar ist, längst eingestellte Gastsystemunterstützung erhalten bleibt oder eine zukünftige VMware-Version noch mit virtuellen Maschinen umgehen kann, die vor zwanzig Jahren angelegt wurden.

Für eine solche Sammlung sind Kompatibilität und langfristige Nutzbarkeit wesentlich wichtiger als die neuesten Virtualisierungsfunktionen.

Umso schöner wäre es, wenn ein vollständig quelloffener Virtualisierungsstack irgendwann dieselbe unkomplizierte und ausgereifte Erfahrung für historische Windows-Umgebungen bieten könnte.

Alte Software auf moderner Hardware

Bis dahin bleibt VMware Workstation für mich eine bemerkenswert leistungsfähige Möglichkeit, diesen Teil der Computergeschichte lebendig zu halten.

Die wichtigste Erkenntnis dieses kleinen Ausflugs ist dabei erstaunlich unspektakulär: Wenn virtuelle Maschinen unter VMware auf einem modernen Windows-Rechner unerklärlich langsam laufen, sollte man zuerst den verwendeten Monitor-Modus überprüfen, bevor man stundenlang nach Fehlern innerhalb der Gastsysteme sucht.

Manchmal entscheidet tatsächlich eine einzige Hypervisor-Einstellung darüber, ob sich Windows 98 kaum noch bedienen lässt oder wieder wunderbar flüssig läuft.

Und wenn ihr mich jetzt entschuldigt: Hier wartet noch eine Installation von Microsoft Bob darauf, gestartet zu werden.