Windows XP, lanciato il 25 ottobre 2001, è ancora oggi ricordato come uno dei sistemi operativi più compatibili di sempre. Riusciva a eseguire senza problemi gran parte del software scritto per Windows 95 e 98, nonostante il passaggio al kernel Windows NT. Dietro questa apparente magia, però, c'era un lavoro enorme fatto di correzioni mirate, progettate da Microsoft per non rendere inutilizzabile il parco software esistente.
Il database segreto in C:\WINDOWS\AppPatch
Il cuore del meccanismo era l'Application Compatibility Database, una raccolta di file binari con estensione .sdb conservati nella cartella C:\WINDOWS\AppPatch. Raymond Chen, storico ingegnere Microsoft, spiegò già nel 2003 che il formato binario serviva per scansionare le informazioni in modo rapidissimo. Al debutto di XP, il database principale Sysmain.sdb conteneva circa 200 correzioni di compatibilità. Il sistema non si limitava a controllare il nome dell'eseguibile: per identificare con precisione un programma usava dimensione, checksum, versione, data e persino la presenza di altri file nella cartella.
Quando trovava una corrispondenza, Windows attivava uno shim, un piccolo strato software interposto tra l'applicazione e il sistema operativo. Lo shim intercettava le chiamate alle API di Windows e poteva modificarne i parametri, alterare il risultato restituito o eseguire codice aggiuntivo. Un esempio classico era Win98VersionLie: se un programma pretendeva di girare solo su Windows 98, XP gli restituiva le informazioni di Windows 98 pur eseguendolo su XP. In pratica, il sistema mentiva deliberatamente all'applicazione. Anche le modalità di compatibilità non erano versioni ridotte di vecchi Windows, ma combinazioni di shim: la modalità Windows 95 in XP raggruppava circa 50 correzioni comuni.
La filosofia 'compatibilità bug per bug'
Il meccanismo poteva spingersi molto più a fondo. Tra gli shim preferiti da Chen c'era EmulateHeap, capace di sostituire l'heap di Windows XP con una replica del gestore di memoria di Windows 95. Alcuni programmi dipendevano da comportamenti non documentati del vecchio sistema, come usare memoria appena liberata o fare supposizioni sugli indirizzi restituiti. Invece di bloccare l'esecuzione, Microsoft forniva al processo un comportamento compatibile con quello a cui era abituato. Chen ha definito questa strategia 'compatibilità bug per bug'. Gli shim, però, non risolvevano tutto: non potevano modificare i confini di sicurezza né correggere incompatibilità dei driver in modalità kernel.
La ragione di tanto impegno era anche economica: ogni applicazione bloccata rappresentava un motivo per non aggiornare Windows. 'Basta un solo programma incompatibile per rovinare un aggiornamento', ha spiegato Chen. Nelle aziende il problema era sentito: quasi ogni organizzazione aveva almeno un'applicazione 'deal-breaker', spesso un software interno in Visual Basic il cui sviluppatore aveva lasciato l'azienda. Il database continuò a essere aggiornato anche dopo il lancio: nell'aprile 2011, un update per XP SP3 portò Sysmain.sdb a 1.206.508 byte, circa 1,2 MB. Per l'utente tutto restava invisibile: doppio clic sull'icona e il programma partiva. Dietro quel gesto c'era una strategia pragmatica che contribuì in modo decisivo alla reputazione di XP come sistema capace di far funzionare quasi tutto.
