Perché Microsoft ha rallentato il riconoscimento del nuovo hardware in Windows 9x?

Eric Voirin, uno sviluppatore che da tempo lavora al progetto Win98 QuickInstall, soluzione che ha come obiettivo quello di eseguire Windows 98 in modo rapido sui sistemi moderni, racconta di aver scoperto un comportamento del sistema Microsoft che lo ha impressionato negativamente. Nel cercare di ottimizzare le prestazioni di Windows 98, Voirin si è accorto che Microsoft ritardava intenzionalmente il riconoscimento dell’hardware.

Lo sviluppatore osserva che l’aggiunta di nuovo hardware in Windows 98 e in Windows 95 dipendeva dal componente sysdm.cpl, ancora oggi parte integrante del Pannello di controllo del sistema operativo. Nonostante Microsoft ne abbia più volte promesso la rimozione, il Pannello di controllo esiste ancora anche in Windows 11. E rimane utile in diverse occasioni.

Voirin ha scoperto che quando Windows 9x rilevava nuovo hardware, inseriva un ritardo di 8 secondi prima di abilitarne l’effettivo utilizzo sul sistema. Con una “patch” applicata a distanza di decenni, il ricercatore ha ridotto tale ritardo intenzionale ad appena 0,3 secondi. Lo si vede in questo post pubblicato su X.

I motivi del ritardo aggiunto da Microsoft in Windows 9x durante il riconoscimento del nuovo hardware

Qualcuno ha scritto che il ritardo volutamente inserito dagli sviluppatori Microsoft nella procedura di riconoscimento dell’hardware sarebbe riconducibile al desiderio di permettere agli utenti di comprendere cosa stava accadendo sul loro sistema. Ci sentiamo di dissentire.

Ai tempi di Windows 9x, le risorse hardware come CPU e RAM erano limitate, e l’hardware spesso impiegava più tempo a rispondere durante la fase di inizializzazione. Il ritardo di 8 secondi poteva aiutare a garantire che i dispositivi avessero completato il processo di auto-inizializzazione prima che il sistema operativo tentasse di accedere o configurare i driver. Il “rallentamento” introdotto da Microsoft era di fatto una misura di sicurezza per evitare comportamenti anomali e veri e propri crash del sistema.

Il tempo di attesa di 8 secondi era suddiviso in due fasi. Innanzitutto, Windows 9x mostrava per tre secondi un nome predefinito generico per la classe o il dispositivo; successivamente visualizzava il nome e il logo del dispositivo dopo aver individuato il driver corretto. Il seguente ritardo di 5 secondi è quello che Microsoft, per questioni di sicurezza, ha aggiunto appositamente.

Assenza dei meccanismi di gestione asincrona

Sebbene Windows 9x supportasse il plug-and-play, la tecnologia era ancora agli inizi. Il sistema poteva necessitare di più tempo per completare il processo di rilevazione e caricamento dei driver, soprattutto quando si trattava di dispositivi complessi o multipli collegati in contemporanea. La presenza di una pausa consentiva al sistema operativo di gestire eventuali conflitti tra dispositivi o errori nella configurazione, riducendo le probabilità di blocchi o malfunzionamenti.

Ai tempi in cui mancavano meccanismi di gestione asincrona come callback, promises, funzioni async e await, i programmatori introducevano un’attesa o sleep in modo tale da garantire che un’operazione considerata “lenta” avesse a disposizione il tempo necessario per completarsi, prima di procedere con il resto del codice. In mancanza di strumenti moderni, il sistema operativo non aveva la flessibilità di verificare in tempo reale se la configurazione fosse terminata e si ricorreva precauzionalmente a una pausa fissa.