Die Konflikte zwischen den Windows-9x-Versionen und der damals „modernen“ Hardware sind viel tiefgreifender, als wir uns vorstellen. Selbst wenn die Hersteller darauf bestanden, dass ihre Produkte für die Betriebssysteme von Redmond „optimiert“ seien, waren die Fehler, die die Benutzer erlebten, kryptisch und frustrierend. Diese Fehler wurden häufiger, je schneller die Prozessoren wurden, und heute sind diese Systeme sehr schwer auszuführen, mit oder ohne Virtualisierung. Michal Necasek vom OS/2 Museum beschloss herauszufinden, warum …
Das Versprechen der Kompatibilität
Wenn man nach Bildern von alten AMD K6-2-Prozessoren sucht, fällt ein besonderes Detail auf: Das Windows-95-Logo ist auf dem Spreader eingraviert. Das soll eine Garantie für Kompatibilität sein, der Beweis, dass diese Chips problemlos mit dem Microsoft-Betriebssystem funktionieren. Nun… sagen wir, „Garantie“ und „Beweis“ sind sehr optimistische Ausdrücke. Die „Windows-Schutzfehler“ waren bei den K6-2 mit 350 MHz intermittierend und bei schnelleren Modellen halbdauerhaft.
Das Absurdeste daran ist, dass Microsoft und AMD fast in einen Krieg darüber gerieten: Redmond wollte 35 Dollar zusätzlich für den „Hotfix“ (obwohl das eigentliche Ziel war, die Benutzer zur Übernahme von Windows 98 zu bewegen), und AMD antwortete, indem es seinen eigenen Patch kostenlos veröffentlichte.
https://old.neoteo.com/mover-el-cursor-en-windows-95-lo-hacia-mas-rapido/Die Untersuchung von Michal Necasek
Und so kommen wir zum Portal des OS/2 Museum, wo Michal Necasek eine Nachricht von einem Bekannten erhielt, die ankündigte, dass Windows 3.11 for Workgroups in virtuellen Maschinen nicht mehr funktionierte. Die ersten Schritte seiner Untersuchung zeigten, dass einer der Hauptfaktoren für das Auslösen des Fehlers der Prozessor ist. Ein Core i7-2600 zeigte ihn nur selten, aber mit einem Ryzen 7 3800X wurde er konstant: Michal tippte „win“, das Windows-Logo erschien … und zurück zu DOS.
Der Rest des Beitrags ist eines Sherlock Holmes würdig. Beim Verfolgen des Debug-Kernels von 3.11 WFW stellte er fest, dass es sich um einen Fehler der Division durch Null irgendwo im Netzwerkbereich handelte. Dieses „irgendwo“ erwies sich als NDIS.386, mit einem spezifischen Problem: Beim Lesen der Zeit mit dem Befehl Get_System_Time, gefolgt von 1.048.576 LOOP-Iterationen, beträgt die maximale Genauigkeit eine Millisekunde. Wenn es schneller ist … könnten Anfang und Ende dasselbe sein, mit einer Differenz von Null, durch die man nicht teilen kann. Bei einem Prozessor mit 100 MHz oder langsamer wäre das nie problematisch, aber bei einem Chip mit 350 MHz – reines Chaos.
Bei Windows 95 tritt das Problem erneut mit NDIS.VXD auf, und eine ähnliche Logik erschien in IOS.VXD, ESDI_506.PDR und SCSIPORT.PDR. Warum schienen Intel-Chips immun? Im Wesentlichen wegen der Unterschiede in der Ausführungsgeschwindigkeit des LOOP: Ein K6-2 mit 350 MHz war sechsmal schneller als sein Pentium-II-Äquivalent. Als die Chips von Santa Clara an Geschwindigkeit gewannen, wurde der Fehler häufiger (z. B. Pentium 4).
Die Geschichte geht weiter mit Microsoft … das ist Microsoft. Der Fehler wurde in den Speichertreibern von Windows 98 (erste Ausgabe) behoben, aber in NDIS war er immer noch da, und dasselbe geschah mit dem Patch für Windows 95 OSR2. Der NDIS-Hotfix kam 2001 (im Jahr des Debüts von XP) und nur für Windows 98, aber die berühmte Zweite Ausgabe beseitigte all diese Probleme an der Wurzel.
https://old.neoteo.com/windows-98-online-y-en-tu-navegador/Schlussfolgerungen
Michal schließt seinen Artikel mit einer sehr interessanten Schlussfolgerung: Keine Bewertung hätte den Fehler erkennen können, als der Code geschrieben wurde. „Was passiert, wenn LOOP in weniger als einer Millisekunde ausgeführt wird?“ war nichts, was die Ingenieure der damaligen Zeit ganz oben auf ihrer Prioritätenliste hatten.
Und da ist auch das Risiko der Annahme. Der Markt ging in nur fünf Jahren von einem Pentium mit 66 MHz zu einem K6-2 mit 350 MHz über und senkte den LOOP von 100 Millisekunden auf weniger als drei. Die Softwareentwickler nahmen an, dass ein solcher Leistungssprung nicht möglich sein würde, und die Hardwareentwickler, dass das Beschleunigen der Befehlsausführung immer etwas Gutes ist.
Zugang zum Artikel: Klicken Sie hier
