I conflitti tra le versioni 9x di Windows e l'hardware «moderno» di ogni epoca sono molto più profondi di quanto immaginiamo. Anche quando i produttori insistevano nel dichiarare che i loro prodotti erano stati «ottimizzati» per i sistemi operativi di Redmond, gli errori che gli utenti sperimentavano erano criptici e frustranti. Questi errori sono diventati più frequenti man mano che i processori aumentavano la loro velocità, e oggi questi sistemi sono molto difficili da eseguire, con o senza virtualizzatore. Michal Necasek del OS/2 Museum ha deciso di scoprire perché…
Il logo di Windows 95 sui processori AMD
Se cerchi immagini di vecchi processori AMD K6-2, noterai un dettaglio molto particolare: il logo di Windows 95 è inciso sul dissipatore. Si suppone che sia una garanzia di compatibilità, la prova che questi chip funzionano senza problemi nel sistema operativo di Microsoft. Beh… diciamo che «garanzia» e «prova» sono espressioni molto ottimistiche. Gli «Errori di protezione di Windows» erano intermittenti sui K6-2 a 350 MHz, e semipermanenti su modelli più veloci.
La cosa più assurda è che Microsoft e AMD quasi finirono in guerra per questo: Redmond voleva ottenere 35 dollari extra (anche se l'obiettivo reale era che gli utenti adottassero Windows 98), e AMD rispose pubblicando la propria patch, gratis. Anche i processori Intel mostrarono una certa resistenza all'inizio, ma in seguito subirono problemi simili: le versioni 9x di Windows fallivano con processori "troppo veloci".
https://old.neoteo.com/mover-el-cursor-en-windows-95-lo-hacia-mas-rapido/L'indagine di Michal Necasek
E così arriviamo al portale dell'OS/2 Museum, dove Michal Necasek ha ricevuto un messaggio da un conoscente, che annunciava che Windows 3.11 for Workgroups non funzionava più nelle macchine virtuali. I primi passi della sua indagine hanno rivelato che uno dei principali fattori per scatenare l'errore è il processore. Un Core i7-2600 lo presentava raramente, ma con un Ryzen 7 3800X diventava costante: Michal scriveva "win", appariva il logo di Windows… e di nuovo a DOS.
Il resto del post è degno di Sherlock Holmes. Rintracciando il kernel debug di 3.11 WFW, ha scoperto che era un errore di divisione per zero in qualche parte della sezione di rete. Quella "qualche parte" si è rivelata essere NDIS.386, con un problema specifico: leggendo il tempo con il comando Get_System_Time seguito da 1.048.576 iterazioni di LOOP, la precisione massima è di un millisecondo. Ora, se è più veloce di così… l'inizio e la fine potrebbero essere gli stessi, con una differenza zero, che non può essere divisa. Su un processore a 100 MHz o più lento, questo non sarebbe mai stato un problema, ma su un chip a 350 MHz, puro caos.
Nel caso di Windows 95, il problema si ripresenta con NDIS.VXD, e una logica simile appariva in IOS.VXD, ESDI_506.PDR e SCSIPORT.PDR. Perché i chip Intel sembravano immuni? In sostanza, per le differenze nella velocità di esecuzione del LOOP: un chip K6-2 a 350 MHz era sei volte più veloce del suo equivalente in Pentium II. Man mano che i chip di Santa Clara guadagnavano velocità, l'errore diventava più frequente (ad esempio, Pentium 4).
Microsoft, sempre Microsoft
La storia continua con Microsoft... essendo Microsoft. L'errore è stato corretto nei driver di archiviazione di Windows 98 (prima edizione), ma in NDIS era ancora lì, e lo stesso è successo con la patch per Windows 95 OSR2. L'hotfix NDIS è arrivato nel 2001 (anno in cui ha debuttato XP) e solo per Windows 98, tuttavia, la famosa Seconda Edizione ha risolto tutti questi problemi alla radice.
https://old.neoteo.com/windows-98-online-y-en-tu-navegador/Conclusione
Michal chiude il suo articolo con una conclusione molto interessante: nessuna valutazione sarebbe stata in grado di rilevare il bug quando il codice è stato scritto. «Che succede se LOOP viene eseguito in meno di un millisecondo?» non era qualcosa che gli ingegneri dell'epoca avevano molto in cima alla loro lista di priorità.
E c'è anche il rischio di fare supposizioni. Il mercato è passato da un Pentium a 66 MHz a un K6-2 a 350 MHz in soli cinque anni, riducendo il LOOP da 100 millisecondi a meno di tre. Gli sviluppatori di software hanno assunto che un salto di prestazioni simile non sarebbe stato possibile, e quelli di hardware, che accelerare l'esecuzione delle istruzioni è sempre una buona cosa.
Accedi all'articolo: Clicca qui
