Perché Windows 98 non è così obsoleto: supporta USB4 e Thunderbolt

Un computer può avere porte USB perfettamente funzionanti e un sistema operativo incapace di utilizzarle. Non perché manchi la compatibilità con mouse, tastiere o memorie esterne, ma perché Windows non conosce il controller che gestisce quelle porte. È uno dei problemi che emergono quando si tenta di installare Windows 98, Windows XP o Windows 7 su hardware molto più recente. Ed è anche il motivo per cui il progetto open source xHCI98 suscita grande interesse: non si limita ad aggiungere USB4 e Thunderbolt a Windows 98, ma dimostra come sia possibile ricostruire parti fondamentali dello stack hardware di un sistema operativo senza modificarne il kernel.

Il lavoro dello sviluppatore Yeo Kheng Meng affronta una questione che va oltre il retrocomputing. Quanto della compatibilità hardware dipende realmente dal sistema operativo e quanto dai driver che ne traducono le richieste?

La risposta arriva da un esperimento particolarmente complesso: far comunicare un software progettato alla fine degli anni ’90 con controller USB 3.x, dispositivi PCI Express e unità NVMe collegate attraverso Thunderbolt.

La vera barriera tra Windows 98 e un computer moderno è il controller USB

Windows 98 nasce quando USB 1.1 rappresentava ancora lo standard di riferimento. Le comunicazioni passano attraverso controller UHCI e OHCI; successivamente USB 2.0 introduce EHCI, mentre USB 3.0 porta una modifica molto più profonda con l’architettura xHCI (eXtensible Host Controller Interface).

Molti chipset recenti non dispongono più dei vecchi controller UHCI, OHCI ed EHCI: Windows 98, Windows XP e persino Windows 7, privi di un driver xHCI appropriato, non riescono quindi a comunicare direttamente con le porte USB.

Il problema può coinvolgere anche un semplice mouse USB 2.0: il dispositivo utilizza uno standard conosciuto dal sistema operativo, ma Windows non sa come impartire comandi al controller che lo collega al computer.

xHCI98 interviene sul livello di astrazione hardware, fornendo una nuova implementazione delle funzioni che permettono ai driver delle periferiche di comunicare con il controller host.

Perché per supportare USB 3.0 è stato necessario sostituire lo stack Microsoft

La prima versione di xHCI98 utilizzava usbport.sys, componente Microsoft progettato per gestire i vecchi controller USB. Era una scelta ragionevole: riutilizzare le funzioni esistenti riduceva la complessità del nuovo driver ma imponeva anche un limite di circa 34 MB/s, perché usbport.sys non conosce le modalità SuperSpeed introdotte con USB 3.0.

A tal proposito, nel descrivere le differenze tra i collegamenti USB, abbiamo già a suo tempo rimarcato che USB-IF, nel 2022, ha presentato una nuova grafica e loghi rinnovati per i dispositivi USB introducendo un punto di rottura rispetto al passato. La novità più rilevante risiede proprio nell’accantonamento della nomenclatura SuperSpeed.

Nel caso del progetto xHCI98, Yeo ha incontrato numerose difficoltà appoggiandosi a usbport.sys, specialmente con dispositivi audio e hub USB.

Così, lo sviluppatore ha deciso di realizzare il driver dedicato xhci98.sys che assume responsabilità precedentemente distribuite tra usbport.sys, usbhub.sys, usbhub20.sys, usbccgp.sys e in parte usbd.sys.

La particolarità è che i driver di classe, quelli che gestiscono mouse, tastiere e altre periferiche, possono rimanere invariati. xHCI98 sostituisce il livello sottostante senza obbligare a una riscrittura dei driver esistenti. È proprio tale separazione a rendere possibile la compatibilità con sistemi operativi così vecchi come Windows 98.

USB4 e Thunderbolt: quali sono le differenze?

USB4 e Thunderbolt non sono due nomi per indicare la stessa tecnologia, anche se condividono buona parte dell’architettura. Il primo nasce infatti dalle specifiche Thunderbolt 3 messe a disposizione da Intel e permette di trasportare attraverso un’unica connessione USB-C diversi protocolli, tra cui USB 3, DisplayPort e PCI Express. La differenza principale riguarda i requisiti obbligatori: USB4 ammette implementazioni con caratteristiche differenti, mentre Thunderbolt 4 impone standard minimi più rigorosi.

Una porta USB4 può, ad esempio, offrire 20 o 40 Gbps e non è obbligata a supportare il tunneling PCIe. Thunderbolt 4 garantisce invece 40 Gbps, il tunneling PCIe con almeno 32 Gbps di banda e requisiti specifici per la gestione dei monitor e la sicurezza. Esistono inoltre versioni più recenti, come Thunderbolt 5 e USB4 Version 2.0, che arrivano a velocità superiori.

Sono informazioni importanti anche nell’ambito del progetto xHCI98: riconoscere un controller USB4 non significa automaticamente poter utilizzare qualsiasi periferica Thunderbolt. Il driver deve gestire i protocolli effettivamente disponibili e, per dispositivi come gli SSD NVMe Thunderbolt, configurare correttamente i tunnel PCIe che rendono accessibile l’unità al sistema operativo.

Thunderbolt e USB4: non basta trasferire dati più velocemente

Un collegamento Thunderbolt può trasportare traffico PCIe, consentendo a un dispositivo esterno di apparire come una vera periferica collegata al bus del computer.

Per gestire tali connessioni, xHCI98 introduce anche xhcicm.sys, un componente che si occupa di autorizzare le periferiche e, quando necessario, configurare i tunnel PCIe e USB 3 attraverso i router USB4.

Su alcuni controller Intel tali operazioni dipendono principalmente dal firmware; su altre piattaforme, comprese alcune soluzioni AMD e ASMedia, serve invece un Connection Manager software capace di costruire autonomamente i percorsi di comunicazione.

Windows 98, tuttavia, non gestisce correttamente l’assegnazione dinamica di tutte le risorse PCI quando una periferica compare dopo l’avvio.

Nei test con un “contenitore” NVMe ORICO USB4 dotato di controller ASMedia ASM2464, il collegamento Thunderbolt funzionava, ma Windows 98 segnalava l’errore 29: al dispositivo mancavano le risorse PCI necessarie per operare.

Per risolvere il problema, il programmatore ha fatto sì che il suo xhcicm.sys si incaricasse anche della cosiddetta enumerazione PCI, configurando numeri di bus, finestre di memoria e interrupt: il driver assume alcune responsabilità che un sistema operativo più recente gestisce in totale autonomia.

Un SSD NVMe supera 1 GB/s: dove si trovano i limiti reali

I risultati dimostrano quanto le prestazioni dipendano dai singoli livelli software. Grazie al lavoro svolto da Yeo, un supporto USB 3.0 raggiunge circa 200-220 MB/s su Windows 98 SE, contro i 34 MB/s della prima versione del driver.

Utilizzando un contenitore NVMe Thunderbolt, Windows 7 raggiunge circa 1.151 MB/s in lettura e 1.013 MB/s in scrittura. Windows 98 SE, invece, si ferma intorno a 210 e 256 MB/s, almeno nella prima versione.

Il collegamento Thunderbolt non rappresenta il collo di bottiglia: a limitare Windows 98 è soprattutto il vecchio sottosistema di memorizzazione.

Per affrontare il problema, il progetto xHCI98 include Stor98, un driver specifico per le unità NVMe, derivato dal lavoro di altri sviluppatori e adattato da Yeo per gestire anche i dispositivi collegati tramite Thunderbolt e USB4.

I due componenti svolgono funzioni differenti: xhcicm.sys configura il collegamento Thunderbolt o USB4 e rende accessibile il dispositivo PCIe; Stor98 si occupa invece di comunicare con il controller NVMe dell’unità SSD. Su Windows 98, che non dispone nativamente di un driver NVMe, entrambi sono necessari per utilizzare un SSD collegato attraverso un tunnel PCIe.

Lo sviluppatore ha inoltre introdotto S98VSD.VXD, un componente per Windows 98 SE e ME che consente di inoltrare a Stor98 richieste di lettura e scrittura fino a 2 MB senza frammentarle in operazioni più piccole. Con trasferimenti di queste dimensioni, le prestazioni documentate raggiungono circa 1.120 MB/s in lettura e 880 MB/s in scrittura.

L’intelligenza artificiale ha contribuito a sviluppare driver kernel

Yeo ha utilizzato assistenti AI, tra cui Claude e Codex, per generare codice, analizzare problemi hardware e verificare le implementazioni.

Ha inoltre costruito usb4-emu, un emulatore basato su QEMU 11 che riproduce controller e dispositivi USB4: in questo modo ha potuto eseguire test ripetibili anche su configurazioni hardware non disponibili fisicamente.

Il lavoro comprende 42 fasi progettuali, 25 documenti dedicati alle decisioni architetturali e 15 analisi di problemi tecnici risolti.

L’AI ha contribuito a ridurre tempi e complessità dello sviluppo, ma la validazione delle interazioni tra firmware, registri PCI, interrupt e periferiche ha richiesto competenze tecniche e verifiche dirette. Con buona pace di tutti coloro che, a priori, per partito preso, bollano negativamente qualunque possibile utilizzo dei modelli generativi. A questo proposito, Linus Torvalds aveva già apostrofato duramente chi rifiuta l’AI usando preconcetti.

Perché xHCI98 è importante oltre il retrocomputing

Il progetto realizzato da Yeo non rende, ovviamente, Windows 98 un sistema adatto all’utilizzo quotidiano: mancano le protezioni di sicurezza moderne e la compatibilità con tutti i controller non è garantita.

Il risultato ha però un significato ingegneristico preciso: l’obsolescenza software non coincide sempre con l’impossibilità tecnica di utilizzare hardware recente. A volte il vero ostacolo è l’assenza di un componente capace di tradurre le richieste del sistema operativo nelle operazioni che il dispositivo si aspetta di vedere supportate e correttamente gestite.

xHCI98 offre inoltre un assaggio di come ci si possa spingere in avanti ricostruendo interfacce, gestendo direttamente il bus PCIe e preservando la compatibilità con i vecchi driver. È una dimostrazione interessante anche per la conservazione di software storico e per lo studio dei sistemi operativi: le loro possibilità non dipendono soltanto da ciò che Microsoft aveva previsto quando li ha progettati.