Windows XP eseguiva quasi tutto perché Microsoft mentiva ai programmi

Windows XP ha costruito una parte importante della sua fama su una caratteristica che gli utenti davano quasi per scontata: installavi un vecchio programma, facevi doppio clic e, molto spesso, funzionava. Dietro quella compatibilità apparentemente naturale c’era però un’enorme quantità di lavoro. Microsoft non si limitò a mantenere API obsolete o a sperare che il software scritto per Windows 95, 98, Me e 2000 continuasse a comportarsi correttamente. Il sistema operativo riconosceva determinate applicazioni e poteva modificare il proprio comportamento esclusivamente per loro, arrivando persino a comunicare informazioni deliberatamente diverse da quelle reali.

La storia torna particolarmente interessante oggi: Windows XP arrivò sul mercato il 25 ottobre 2001 e compie quindi 25 anni proprio ad ottobre 2026.

Era il prodotto con cui Microsoft portava definitivamente l’architettura Windows NT anche sul mercato consumer, abbandonando la linea tecnica derivata da Windows 95. XP cambiava il kernel, cambiava la gestione della memoria, molte API; ma, allo stesso tempo, bisognava evitare che migliaia di programmi smettessero improvvisamente di funzionare. Una parte della risposta si chiamava Application Compatibility Database.

Windows XP sapeva quali programmi avevano problemi

Raymond Chen, ingegnere Microsoft coinvolto nello sviluppo di Windows per oltre 30 anni, raccontò già nel 2003 che i dati necessari alla compatibilità tra Windows 2000 e XP risiedevano nella directory C:\WINDOWS\AppPatch. Microsoft li organizzava in formato binario per permettere ricerche molto rapide: non si trattava quindi di un semplice elenco testuale contenente nomi di programmi problematici.

Il cuore del meccanismo era costituito da file con estensione .sdb, cioè Shim Database. La documentazione Microsoft descrive ancora oggi questi database come strutture binarie indicizzate usate dall’infrastruttura di compatibilità per identificare applicazioni e associare loro specifiche correzioni.

Controllare soltanto il nome dell’eseguibile sarebbe stato troppo rischioso: due versioni dello stesso programma potevano avere comportamenti completamente differenti. Il motore poteva quindi confrontare nome, dimensione, checksum, versione e data del file; poteva inoltre verificare la presenza di altri file nella stessa directory o nelle sottocartelle.

In pratica, Microsoft poteva stabilire che una particolare release di un programma necessitava di un workaround e lasciare intatta quella successiva, già corretta dal produttore. È un approccio molto più raffinato di quanto suggerisca la classica casella “Esegui il programma in modalità compatibilità“.

Cosa sono davvero gli shim di Windows

Una volta identificato il programma, Windows poteva applicare uno o più shim: piccoli strati software inseriti tra l’applicazione e determinate funzioni del sistema operativo.

Sono descritti come hook verso funzioni che possono intercettare una chiamata API, modificarne i parametri, alterare il risultato restituito oppure eseguire altro codice prima di richiamare la funzione originale.

Supponiamo che un vecchio programma chiami una funzione di Windows aspettandosi un determinato comportamento. XP potrebbe produrre un risultato differente rispetto a Windows 98: con uno shim, quella singola applicazione può invece ricevere la risposta che si aspetta, mentre il resto del sistema continua a funzionare secondo le regole di XP.

La modalità compatibilità non esegue una vecchia copia di Windows, non crea una macchina virtuale con Windows 95 o Windows 2000, né sostituisce globalmente il comportamento del sistema operativo.

Windows poteva perfino mentire sulla propria versione

Uno dei casi più semplici riguarda i programmi che controllavano la versione di Windows in uso. Molto software dell’epoca non chiedeva realmente “il sistema possiede la funzione che mi serve?”, ma adottava logiche del tipo “se Windows non è esattamente la versione che conosco, interrompi l’esecuzione“.

Un’applicazione scritta quando Windows 98 rappresentava l’ultima release disponibile poteva rifiutarsi di partire su XP anche se tutte le API necessarie continuavano a esistere.

Microsoft disponeva di shim della famiglia VersionLie (il nome è tutto un programma; “Lie” significa “bugia“, “menzogna“) capaci di presentare al programma informazioni differenti sulla versione del sistema operativo. L’applicazione credeva quindi di trovarsi, per esempio, davanti alla versione Windows per cui era stata progettata e proseguiva normalmente.

È da qui che nasce l’idea, volutamente provocatoria, di Windows che “mente” alle applicazioni: in realtà è proprio una forma mirata di virtualizzazione del comportamento dell’API.

Chen ha però chiarito più volte che questi strumenti non dovevano diventare una scorciatoia per gli sviluppatori. In un intervento del 2010 sulla modalità compatibilità, spiegava che se un programma riprende a funzionare grazie a VersionLie, la soluzione corretta consiste nel correggere il controllo della versione nel software. La modalità compatibilità serve a proteggere il cliente dagli errori delle applicazioni esistenti, non a giustificare nuovi programmi scritti male.

EmulateHeap: dentro Windows sopravviveva parte di Windows 95

Alcuni workaround erano ancora più sorprendenti. Uno degli esempi preferiti dallo stesso Chen è EmulateHeap, una correzione che intercettava le funzioni di gestione dello heap usate dal programma e riproduceva con grande precisione il comportamento del gestore della memoria di Windows 95.

Lo heap è una regione di memoria dalla quale un processo ottiene dinamicamente blocchi necessari durante l’esecuzione. Un’applicazione correttamente progettata non dovrebbe dipendere da dettagli come l’indirizzo che il sistema assegnerà alla prossima allocazione oppure da cosa accade fisicamente a un’area subito dopo che il programma l’ha liberata.

Alcuni programmi, invece, facevano proprio questo. Potevano liberare un blocco e continuare a leggerlo, scrivere oltre i limiti di un buffer oppure aspettarsi che una nuova allocazione restituisse esattamente lo stesso indirizzo usato in precedenza. Su Windows 95 tali errori potevano rimanere invisibili per puro caso; cambiando memory manager, venivano puntualmente a galla.

Con EmulateHeap Microsoft adottò una soluzione radicale: secondo la spiegazione pubblicata da Raymond Chen, gli sviluppatori presero il codice del gestore dello heap di Windows 95, lo ricompilarono e lo integrarono nell’infrastruttura di compatibilità. Quando necessario, quindi, codice risalente a Windows 95 tornava realmente in esecuzione all’interno del processo problematico.

La compatibilità di XP non era magia, ma ingegneria delle eccezioni

La documentazione Microsoft attuale conserva ancora la descrizione fondamentale dell’Application Compatibility Database. La tecnologia si è evoluta con le successive generazioni di Windows, ma l’idea di fondo resta riconoscibile.

Vista da fuori, la retrocompatibilità può sembrare una qualità intrinseca di un sistema operativo: Windows XP “era fatto bene”, quindi eseguiva programmi molto vecchi. In realtà, una parte di quella compatibilità derivava proprio dalla conoscenza dettagliata dei difetti del software esistente e dalla disponibilità di Microsoft a costruire correzioni chirurgiche intorno a quei difetti.

Windows XP non pretendeva che tutto il software precedente rispettasse improvvisamente le regole; quando possibile, adattava temporaneamente le regole al programma.

A volte bastava falsificare un numero di versione; in altri casi serviva intercettare un’API. Nei casi più estremi, Windows arrivava a riesumare il vecchio gestore dello heap di Windows 95.

Per l’utente, nulla di tutto ciò era visibile. Si inseriva il CD, si installava il programma, si faceva doppio clic sull’icona e l’applicazione partiva. 25 anni dopo, sapere quanto lavoro servisse per ottenere quel semplice risultato rende forse ancora più comprensibile la reputazione che Windows XP continua a portarsi dietro.