Konflikty między wersjami 9x systemu Windows a „nowoczesnym” sprzętem z każdej epoki są znacznie głębsze, niż się wydaje. Nawet gdy producenci twierdzili, że ich produkty zostały „zoptymalizowane” pod systemy operacyjne Redmond, błędy doświadczane przez użytkowników były kryptyczne i frustrujące. Błędy te stawały się coraz częstsze wraz ze wzrostem szybkości procesorów, a dziś uruchamianie tych systemów jest bardzo trudne, z wirtualizacją lub bez. Michal Necasek z OS/2 Museum postanowił dowiedzieć się, dlaczego…
AMD K6-2 i logo Windows 95
Jeśli szukasz zdjęć starych procesorów AMD K6-2, zauważysz bardzo szczególny szczegół: logo Windows 95 jest wytłoczone na spreaderze. Zapewne miało to być gwarancją zgodności, dowodem, że te chipy działają bez problemów w systemie operacyjnym Microsoftu. Cóż… powiedzmy, że „gwarancja” i „dowód” to bardzo optymistyczne określenia. „Błędy ochrony systemu Windows” były sporadyczne w modelach K6-2 350 MHz, a w szybszych modelach – prawie trwałe.
Najbardziej absurdalne jest to, że Microsoft i AMD prawie się o to pokłócili: Redmond chciał uzyskać dodatkowe 35 dolarów za „łatkę” (choć prawdziwym celem było skłonienie użytkowników do przejścia na Windows 98), a AMD odpowiedziało publikując własną, darmową łatkę. Procesory Intela początkowo stawiały opór, ale później doświadczyły podobnych problemów: wersje 9x systemu Windows zawieszały się na „zbyt szybkich” procesorach.
Badania Michala Necaska
I tak docieramy do portalu OS/2 Museum, gdzie Michal Necasek otrzymał wiadomość od znajomego, że Windows 3.11 for Workgroups nie działa już na maszynach wirtualnych. Pierwsze kroki w jego badaniu wykazały, że jednym z głównych czynników wywołujących błąd jest procesor. Core i7-2600 wywoływał go rzadko, ale przy Ryzen 7 3800X stał się stały: Michał pisał „win”, pojawiało się logo Windows… i powrót do DOS.
Sedno problemu
Reszta wpisu jest godna Sherlocka Holmesa. Śledząc debugujące jądro 3.11 WFW, odkrył, że to błąd dzielenia przez zero w jakiejś części sekcji sieciowej. Tą „jakąś częścią” okazał się NDIS.386, z konkretnym problemem: po odczytaniu czasu poleceniem Get_System_Time, a następnie wykonaniu 1 048 576 pętli LOOP, maksymalna precyzja wynosi jedną milisekundę. Jeśli jest szybsze niż to… początek i koniec mogą być takie same, z różnicą zerową, przez którą nie można dzielić. Na procesorze 100 MHz lub wolniejszym to nigdy nie stanowiłoby problemu, ale na chipie 350 MHz – czysty chaos.
W przypadku Windows 95 problem pojawia się ponownie z NDIS.VXD, a podobna logika występowała w IOS.VXD, ESDI_506.PDR i SCSIPORT.PDR. Dlaczego chipy Intela wydawały się odporne? Zasadniczo ze względu na różnice w szybkości wykonywania LOOP: chip K6-2 350 MHz był sześć razy szybszy niż odpowiednik w Pentium II. Wraz ze wzrostem szybkości chipów z Santa Clara błąd stawał się częstszy (np. Pentium 4).
Microsoft i poprawki
Historia toczy się dalej z Microsoftem... będącym Microsoftem. Błąd został naprawiony w sterownikach pamięci masowej Windows 98 (pierwsza edycja), ale w NDIS nadal istniał, podobnie jak w łatce dla Windows 95 OSR2. Poprawka NDIS pojawiła się w 2001 roku (kiedy zadebiutował XP) i tylko dla Windows 98, jednak słynna Druga Edycja usunęła te problemy u podstaw.
https://old.neoteo.com/windows-98-online-y-en-tu-navegador/Wnioski
Michal kończy swój artykuł bardzo interesującym wnioskiem: żadna ocena nie byłaby w stanie wykryć tego błędu w momencie pisania kodu. „Co się stanie, jeśli LOOP wykona się w czasie krótszym niż milisekunda?” nie było czymś, co ówcześni inżynierowie mieli wysoko na liście priorytetów.
Jest też ryzyko założeń. Rynek przeszedł od Pentium 66 MHz do K6-2 350 MHz w zaledwie pięć lat, skracając LOOP ze 100 milisekund do mniej niż trzech. Programiści zakładali, że taki skok wydajności nie będzie możliwy, a producenci sprzętu, że przyspieszanie wykonywania instrukcji zawsze jest dobre.
Dostęp do artykułu: Kliknij tutaj
