Compatibilità Windows XP: così Microsoft ‘mentiva’ ai programmi

Windows XP eseguiva quasi qualsiasi programma — anche software scritto anni prima del suo debutto nel 2001 — grazie a un segreto poco noto: la compatibilità Windows XP si appoggiava a un database nascosto di applicazioni problematiche e a una serie di trucchi chiamati shim. Quando il sistema riconosceva uno di quei programmi, poteva letteralmente “mentirgli” sulla versione di Windows in esecuzione, o persino restituirgli il gestore di memoria di Windows 95. Non era magia, né intelligenza artificiale: era ingegneria pura, documentata dagli stessi sviluppatori Microsoft. Dietro la leggendaria affidabilità di XP c’è una storia tecnica precisa, fatta di scelte deliberate.

Cos’è la compatibilità di Windows XP

La compatibilità Windows XP è l’insieme di tecnologie che permette a software scritto per versioni precedenti di Windows di funzionare su XP. Il cuore è l’Application Compatibility Database: un file binario indicizzato (Sysmain.sdb) conservato nella cartella C:\WINDOWS\AppPatch, che al lancio di XP conteneva circa 200 correzioni di compatibilità.

Secondo la documentazione Microsoft sulle tecnologie di compatibilità di Windows XP, il sistema non si limitava a leggere il nome del file .exe. Per riconoscere un’applicazione incrociava più dati:

• nome, dimensione del file e checksum;
• numero di versione e data;
• la presenza di altri file nella stessa cartella.

Così una correzione poteva colpire una versione specifica di un programma senza toccare quella più recente, che invece funzionava bene. L’ingegnere Microsoft Raymond Chen, da oltre trent’anni nel team di Windows, ha spiegato nel 2003 che il formato binario serviva a consentire una scansione rapida all’avvio.

Come funzionano gli shim: Windows “mentiva” alle app

Uno shim è una piccola funzione “stub” che si inserisce tra l’applicazione e le API di Windows. Intercetta la chiamata, può modificare ciò che l’app invia o ciò che Windows restituisce, ed eseguire codice proprio prima di passare la mano alla funzione reale del sistema.

L’esempio più celebre è lo shim Win98VersionLie: alcune app si rifiutavano di partire se non vedevano una precisa versione di Windows, così questo shim restituiva le informazioni di Windows 98 a prescindere dal sistema reale. In pratica Windows mentiva all’applicazione, che non se ne accorgeva. Chen, però, non amava che gli sviluppatori ci facessero affidamento: nel 2010 scrisse che la modalità compatibilità esiste per il cliente, non per il programma mal scritto.

Le “modalità compatibilità” non sono mini-versioni di vecchi Windows: ognuna è semplicemente un pacchetto di shim e flag. La modalità Windows 95 su XP, per esempio, raggruppava una cinquantina delle correzioni più comuni. Lo stesso principio — intercettare e riscrivere il comportamento di un programma senza modificarne il codice — vive ancora oggi in strumenti che usano la DLL injection per modernizzare le finestre Win32.

Oltre la versione: EmulateHeap e la memoria di Windows 95

Falsare un numero di versione è il trucco più semplice. Ben più sofisticato è lo shim EmulateHeap, che — nelle parole di Chen — sostituisce l’heap standard con una copia esatta del gestore di memoria di Windows 95.

L’heap è il meccanismo con cui un programma chiede memoria al sistema operativo. Alcune vecchie applicazioni dipendevano in modo troppo stretto da come Windows 95 gestiva quella memoria, e si rompevano sui sistemi più recenti. Invece di dire all’utente che l’app era scritta male, Windows le restituiva il gestore di memoria con cui era “cresciuta”.

Microsoft faceva operazioni simili da molto prima di XP. Come ha raccontato l’ex programmatore Joel Spolsky, il gioco SimCity leggeva memoria che aveva appena liberato: Windows 95 fu quindi rilasciato con codice che riconosceva SimCity e faceva girare l’allocatore in una modalità speciale, che non liberava subito la memoria. Chen chiama questo approccio “compatibilità bug-for-bug”.

Perché Microsoft lo faceva (e cosa uno shim non può fare)

La logica era commerciale, non estetica. In un post del 2003, Chen osservò che ogni programma bloccato è un motivo in più per non aggiornare Windows: basta un singolo software incompatibile per rovinare un intero aggiornamento. Immaginate un responsabile IT il cui gestionale smette di funzionare su XP: se il fornitore chiede 150 dollari a copia per la nuova versione, il costo della migrazione schizza — ammesso che il fornitore esista ancora.

Questa filosofia ha un rovescio della medaglia sul fronte sicurezza. In un articolo del 2017, Chen ha spiegato che la modalità compatibilità Windows 2000 fa caricare le DLL con regole precedenti alla più sicura SafeDllSearchMode: una scelta deliberata per le app che dipendono da quelle regole. E gli shim hanno limiti netti — agiscono solo dentro il processo dell’app, come mostra la tabella.

Lo stesso principio di fondo — far girare software non nativo tramite un layer di compatibilità dedicato — è ancora oggi al centro di Windows, che continua a trascinare alcune “stranezze” storiche proprio perché del software vecchio le dà per scontate.

Domande frequenti

Cos’è uno shim di compatibilità in Windows?

Uno shim è una piccola funzione che si inserisce tra un programma e le API di Windows per correggerne il comportamento. Intercetta le chiamate dell’app e può modificare ciò che il sistema restituisce — per esempio la versione di Windows — così un software vecchio continua a funzionare senza essere riscritto. Microsoft li chiama ufficialmente “compatibility fix”.

Che cos’è il file Sysmain.sdb di Windows XP?

Sysmain.sdb è il database di compatibilità principale di Windows XP: un file binario indicizzato nella cartella C:\WINDOWS\AppPatch. Contiene l’elenco delle applicazioni problematiche e le correzioni (shim) da applicare; al lancio di XP erano circa 200. Il formato binario serviva a consentire una scansione rapida all’avvio dei programmi.

Perché si dice che Windows XP “mentiva” ai programmi?

Perché alcuni shim restituivano all’applicazione informazioni false ma utili. Lo shim Win98VersionLie, per esempio, diceva al programma di trovarsi su Windows 98 anche quando girava su XP, aggirando i controlli di versione troppo rigidi. L’app riceveva la risposta che si aspettava e funzionava, senza accorgersi dell’inganno.

Gli shim esistono ancora nelle versioni moderne di Windows?

Sì, il meccanismo di compatibilità basato su database e shim esiste ancora nelle versioni moderne di Windows. Il sistema continua inoltre a trascinare alcune “stranezze” storiche proprio perché del software vecchio le dà per scontate. La filosofia resta quella descritta da Microsoft per XP: non rompere i programmi su cui gli utenti fanno affidamento.

Conclusione

La leggendaria compatibilità Windows XP non nasceva da un codice perfetto, ma da un lavoro paziente di “bugie tecniche” mirate: un database di applicazioni, centinaia di shim e la volontà di non lasciare indietro nessun programma. È una lezione di ingegneria del software ancora attuale, in un’epoca in cui tutto diventa abbonamento e nulla sembra più “per sempre”. E tu, ti è mai capitato di tenere in vita un vecchio programma a tutti i costi? Raccontalo nei commenti. #tuttelevitediunmaker