De conflicten tussen de 9x-versies van Windows en de 'moderne' hardware van elke tijd zijn veel dieper dan we ons voorstellen. Zelfs toen fabrikanten erop stonden te verklaren dat hun producten waren 'geoptimaliseerd' voor de besturingssystemen van Redmond, waren de fouten die gebruikers ervoeren cryptisch en frustrerend. Die fouten kwamen steeds vaker voor naarmate processors sneller werden, en vandaag de dag zijn die systemen erg moeilijk uit te voeren, met of zonder virtualisatie. Michal Necasek van het OS/2 Museum besloot uit te zoeken waarom...
Een vreemde compatibiliteitsgarantie
Als je zoekt naar afbeeldingen van oude AMD K6-2-processors, valt een heel specifiek detail op: het Windows 95-logo is in de spreader gegraveerd. Dat zou een compatibiliteitsgarantie moeten zijn, het bewijs dat die chips zonder problemen in het besturingssysteem van Microsoft werken. Nou... laten we zeggen dat 'garantie' en 'bewijs' zeer optimistische uitdrukkingen zijn. De "Windows-beschermingsfouten" waren intermitterend op de K6-2 van 350 MHz, en semi-permanent op snellere modellen.
De strijd tussen Microsoft en AMD
Het meest absurde is dat Microsoft en AMD hier bijna oorlog om voerden: Redmond wilde 35 dollar extra voor de 'hotfix' (hoewel het echte doel was dat gebruikers Windows 98 zouden gebruiken), en AMD reageerde door zijn eigen patch gratis te publiceren. Intel-processors vertoonden aanvankelijk wat weerstand, maar kregen later te maken met vergelijkbare problemen: de 9x-versies van Windows faalden met 'te snelle' processors.
https://old.neoteo.com/mover-el-cursor-en-windows-95-lo-hacia-mas-rapido/De zoektocht naar de oorzaak
En zo komen we bij het portaal van het OS/2 Museum, waar Michal Necasek een bericht ontving van een kennis, waarin werd aangekondigd dat Windows 3.11 for Workgroups niet meer werkte op virtuele machines. De eerste stappen in zijn onderzoek onthulden dat een van de belangrijkste factoren voor het activeren van de fout de processor is. Een Core i7-2600 vertoonde het zelden, maar met een Ryzen 7 3800X werd het constant: Michal typte 'win', het Windows-logo verscheen... en terug naar DOS.
De ware boosdoener: NDIS.386
De rest van het artikel is Sherlock Holmes waardig. Door de debug-kernel van 3.11 WFW te traceren, bevestigde hij dat het een deling-door-nul-fout was ergens in het netwerkgedeelte. Die 'ergens' bleek NDIS.386 te zijn, met een specifiek probleem: bij het lezen van de tijd met het commando Get_System_Time gevolgd door 1.048.576 LOOP-iteraties, is de maximale precisie één milliseconde. Als het sneller is dan dat, zouden het begin en het einde hetzelfde kunnen zijn, met een verschil van nul, dat niet kan worden gedeeld. Op een processor van 100 MHz of trager zou dit nooit problematisch zijn, maar op een chip van 350 MHz: pure chaos.
Hetzelfde probleem in Windows 95
In het geval van Windows 95 doet het probleem zich opnieuw voor met NDIS.VXD, en vergelijkbare logica verscheen in IOS.VXD, ESDI_506.PDR en SCSIPORT.PDR. Waarom leken Intel-chips immuun? In essentie vanwege de verschillen in de uitvoeringssnelheid van de LOOP: een K6-2-chip van 350 MHz was zes keer sneller dan zijn equivalent in Pentium II. Naarmate de chips van Santa Clara sneller werden, kwam de fout vaker voor (bijv. Pentium 4).
Microsoft stelt de oplossing uit
Het verhaal gaat verder met Microsoft... die Microsoft is. De fout werd gecorrigeerd in de opslagstuurprogramma's van Windows 98 (eerste editie), maar in NDIS was hij er nog steeds, en hetzelfde gebeurde met de patch voor Windows 95 OSR2. De NDIS-hotfix arriveerde in 2001 (het jaar waarin XP debuteerde) en alleen voor Windows 98, maar de beroemde Tweede Editie pakte al die problemen vanaf de wortel aan.
https://old.neoteo.com/windows-98-online-y-en-tu-navegador/De conclusie van Michal
Michal sluit zijn artikel af met een zeer interessante conclusie: geen enkele evaluatie zou de bug hebben kunnen detecteren toen de code werd geschreven. "Wat gebeurt er als LOOP in minder dan een milliseconde wordt uitgevoerd?" was niet iets waar de ingenieurs van die tijd hoog op hun prioriteitenlijst hadden staan.
En er is ook het risico van aannames. De markt ging van een Pentium van 66 MHz naar een K6-2 van 350 MHz in slechts vijf jaar tijd, waardoor de LOOP van 100 milliseconden naar minder dan drie daalde. Softwareontwikkelaars namen aan dat zo'n prestatieverbetering niet mogelijk zou zijn, en hardwareontwikkelaars dat het versnellen van instructies altijd iets goeds is.
Toegang tot het artikel: Klik hier
