Scopri come Windows XP garantiva la compatibilit con i vecchi programmi: database di correzioni, versioni simulate ed EmulateHeap tra ingegneria e illusione.
Rimani aggiornato con WebMasterPoint
Per rendere compatibili i vecchi programmi, Windows XP ricorse a un database di correzioni e a piccoli inganni: dalla versione dichiarata al recupero del gestore di memoria di Windows 95, un equilibrio tra ingegneria e illusione.
Il 25 ottobre 2001 Microsoft lanci Windows XP, un sistema operativo che 25 anni dopo, nell’ottobre 2026, continua a essere ricordato per la sua capacit di eseguire programmi scritti decenni prima. Dietro quella semplicit apparente si nascondeva un sistema di compatibilit programmata che modificava il comportamento del sistema operativo per adattarsi a ogni singola applicazione, arrivando persino a fornire informazioni deliberatamente false ai software pi vecchi.
Il database delle correzioni che trasform XP in un mago della compatibilit
Tutto iniziava con l’Application Compatibility Database, una raccolta di file binari .sdb memorizzati nella cartella C:\WINDOWS\AppPatch. Secondo le spiegazioni tecniche pubblicate da Microsoft, questi file non erano semplici elenchi testuali, ma strutture indicizzate che permettevano al sistema di identificare un programma problematico in millisecondi. Il motore di compatibilit poteva analizzare:
- il nome dell’eseguibile,
- la sua dimensione,
- il checksum,
- la versione,
- la data di creazione e persino la presenza di altri file nella stessa directory.
In questo modo Microsoft poteva applicare una correzione specifica a una particolare release di un programma, lasciando intatta una versione successiva gi corretta dallo sviluppatore.
Quando Windows XP mentiva sulla propria versione
Uno degli stratagemmi pi semplici ma efficaci era la famiglia di shim chiamata VersionLie. Quando un vecchio programma controllava la versione del sistema operativo e rifiutava di avviarsi perch non corrispondeva a quella attesa, XP intercettava la richiesta e restituiva un valore fittizio. L’applicazione credeva cos di trovarsi davanti al sistema operativo per cui era stata progettata e proseguiva l’esecuzione senza problemi. Raymond Chen, ingegnere Microsoft con oltre 30 anni di esperienza nello sviluppo di Windows, ha ripetutamente chiarito che questi “shim” non erano una scusa per gli sviluppatori pigri, ma uno strumento temporaneo per proteggere gli utenti dai bug del software esistente.
EmulateHeap: far rivivere il gestore della memoria di Windows 95
Alcuni programmi presentavano difetti ancora pi profondi, come la dipendenza da dettagli interni del gestore della memoria (heap) di Windows 95. Applicazioni che liberavano un blocco di memoria e poi continuavano a leggerlo, o che si aspettavano che una nuova allocazione restituisse lo stesso indirizzo usato in precedenza, funzionavano solo grazie a comportamenti casuali del vecchio sistema operativo. Con XP, Microsoft risolse il problema in modo radicale: prese il codice originale del gestore dello heap di Windows 95, lo ricompil e lo integr nell’infrastruttura di compatibilit. Quando necessario, quel codice storico veniva effettivamente eseguito all’interno del processo moderno, una soluzione che andava ben oltre la semplice intercettazione delle chiamate API.
Un equilibrio tra ingegneria e illusione
L’approccio di Microsoft non era privo di rischi. Ogni shim aggiunto rappresentava una regola specifica che il sistema operativo doveva seguire solo per quel particolare programma. La documentazione attuale di Microsoft descrive ancora questi meccanismi come eccezioni mirate, non come una sostituzione generalizzata del comportamento del sistema. La modalit di compatibilit non creava una macchina virtuale con una vecchia versione di Windows, n eseguiva una copia completa del sistema operativo precedente. Si limitava a inserire uno strato software sottile tra l’applicazione e il kernel moderno, modificando solo ci che era strettamente necessario.