A milioni di utenti la menzione di Windows XP provoca un'ondata di nostalgia non del tutto immotivata: molti ricordano che era in grado di far funzionare praticamente ogni software. Si installava un vecchio programma, magari scritto anni prima per Windows 95 o Windows 98, e nella maggior parte dei casi esso funzionava senza problemi. A distanza di quasi 25 anni dal debutto del sistema operativo, avvenuta il 25 ottobre 2021, tornano a far parlare di sé certi dettagli tecnici di uno dei meccanismi che hanno contribuito a costruire quella reputazione: un vasto database nascosto di correzioni che permetteva a Windows di modificare il proprio comportamento per singole applicazioni e, in alcuni casi, perfino di fornire loro informazioni non esattamente corrispondenti alla realtà.

Questa tecnologia era parte dell'infrastruttura di compatibilità sviluppata da Microsoft per facilitare il passaggio alla nuova architettura Windows NT nel mercato consumer. Con Windows XP, infatti, l'azienda abbandonò definitivamente la base tecnologica utilizzata da Windows 95, 98 e Me, introducendo un sistema molto diverso sotto il cofano. Questo cambiamento avrebbe potuto causare l'incompatibilità di migliaia di applicazioni esistenti, uno scenario che Microsoft voleva evitare a tutti i costi. Al centro del meccanismo si trovava l'Application Compatibility Database, una raccolta di file binari con estensione .sdb conservati nella cartella C:\WINDOWS\AppPatch. Come spiega Raymond Chen, storico ingegnere Microsoft coinvolto nello sviluppo di Windows per oltre trent'anni, questi database erano organizzati in formato binario indicizzato per consentire una ricerca estremamente rapida delle informazioni necessarie all'applicazione delle correzioni.

L'identificazione dei programmi non avveniva semplicemente attraverso il nome del file eseguibile. Windows XP poteva confrontare numerosi elementi, tra cui dimensione del file, checksum, numero di versione, data di compilazione e persino la presenza di file specifici all'interno della stessa cartella dell'applicazione. Questo approccio consentiva di distinguere tra versioni differenti dello stesso software e applicare una correzione solo alle release realmente problematiche. Una volta riconosciuto un programma incompatibile, entravano in gioco gli shim, piccoli livelli di intermediazione software inseriti tra l'applicazione e le funzioni del sistema operativo. Gli shim potevano intercettare una chiamata alle API di Windows, modificare i parametri in ingresso, alterare il risultato restituito oppure eseguire codice aggiuntivo prima di passare il controllo alla funzione originale.

Uno dei casi più noti riguardava i programmi che verificavano rigidamente la versione del sistema operativo prima di avviarsi. Molte applicazioni dell'epoca non controllavano l'effettiva disponibilità delle funzionalità necessarie, ma si limitavano a verificare che Windows corrispondesse a una specifica versione conosciuta. Se il numero restituito era diverso da quello previsto, il programma si rifiutava di partire. Per aggirare il problema, Microsoft realizzò shim capaci di comunicare all'applicazione una versione diversa da quella realmente installata sul computer. In pratica, il sistema operativo "mentiva" deliberatamente al software. Il programma credeva di trovarsi davanti a Windows 98 o a un'altra versione attesa, mentre in realtà era in esecuzione su Windows XP. Grazie a questo semplice stratagemma, molte applicazioni potevano continuare a funzionare senza che gli sviluppatori fossero costretti a modificarle.

Per approfondire:

Trent'anni fa Windows NT 4.0

ReactOS supporta i driver grafici WDDM: migliora la compatibilità con le GP...

Windows XP, la chiave pirata più nota fu colpa di Microsoft: lo svela ex sv...

Fine del supporto a Windows 10: un utente fa causa a Microsoft per obsolescenza ...

Alcune correzioni erano ancora più sofisticate. Tra gli esempi più celebri figura EmulateHeap, indicato dallo stesso Chen come uno degli shim più interessanti mai realizzati. La funzione sostituiva il gestore della memoria standard di Windows XP con una replica del gestore utilizzato da Windows 95, consentendo ai programmi più vecchi di continuare a comportarsi come si aspettavano. Il problema nasceva dal fatto che molte applicazioni erano state sviluppate facendo affidamento su comportamenti non documentati del sistema operativo. Alcuni programmi continuavano a utilizzare blocchi di memoria già liberati oppure presumevano che una nuova allocazione producesse sempre lo stesso indirizzo di memoria. Questi comportamenti potevano funzionare casualmente con Windows 95, ma smettevano di funzionare quando il gestore della memoria veniva riscritto nelle versioni successive. EmulateHeap riproduceva il vecchio comportamento per il singolo programma interessato, evitando arresti anomali e malfunzionamenti.

La strategia della compatibilità estrema non era peraltro nata con Windows XP. Una storia famosa raccontata dall'ex sviluppatore Microsoft Joel Spolsky riguarda SimCity, che conteneva un bug legato all'utilizzo di memoria già rilasciata. Per evitare che uno dei videogiochi più popolari dell'epoca smettesse di funzionare, già Windows 95 includeva codice specifico in grado di rilevare il programma e modificare il comportamento dell'allocatore di memoria. Secondo Raymond Chen, la ragione dietro queste scelte era eminentemente pratica. Ogni applicazione incompatibile avrebbe rappresentato un motivo in più per rinunciare all'aggiornamento del sistema operativo. In un celebre intervento l'ingegnere spiegò che poteva bastare un solo software essenziale non funzionante per compromettere l'intero progetto di migrazione di un'azienda verso una nuova versione di Windows.

La compatibilità era quindi diventata una questione commerciale oltre che tecnica. Microsoft preferiva inserire eccezioni mirate, talvolta persino replicando difetti storici del sistema, piuttosto che costringere imprese e utenti a sostituire software costoso o non più supportato. Chen ha definito questo approccio «compatibilità bug per bug», una filosofia che puntava a replicare fedelmente anche determinati comportamenti errati quando questi risultavano necessari alla sopravvivenza delle applicazioni esistenti. Nel corso degli anni il database delle correzioni continuò a crescere. I vari Service Pack contenevano nuove regole per il file Sysmain.sdb, segno che Microsoft continuò a monitorare e risolvere problemi di compatibilità per gran parte del ciclo di vita del sistema operativo.

Consigliamo la lettura di:

Microsoft lancia le Crocs di Windows XP con Bliss, Clippy e MSN: nostalgia ai tu...

Windows XP gira emulato nel browser. Un tuffo nella nostalgia dei primi anni 200...

Linux dice addio ai 486 e ai primi Pentium

Windows 10, supporto esteso anche per gli utenti privati

La leggendaria capacità di Windows XP di eseguire software scritto per generazioni precedenti non era dunque il risultato di una magica compatibilità universale integrata nel sistema in modo automatico. Dietro l'apparente semplicità si nascondeva un enorme lavoro di ingegneria, basato su database specializzati, correzioni mirate e modifiche dinamiche del comportamento del sistema operativo. Per l'utente finale tutto ciò rimaneva invisibile: bastava fare doppio clic sull'icona di un programma per vederlo partire, senza sapere che Windows stava silenziosamente adattando le regole del gioco per farlo funzionare.

Proposte di lettura:

Windows 11 è praticamente uno spyware

La canzone di Janet Jackson che mandava in crash i Pc

Windows 98 è ancora vivo e vegeto sulla sonda Mars Express

20 anni di Windows XP, il sistema operativo che si rifiuta di morire