Windows 95: il trucco nascosto che salvava il sistema dagli installer difettosi

La gestione delle versioni dei file di sistema rappresenta uno dei problemi più sottovalutati nella storia dei sistemi operativi desktop. Durante la transizione tra ambienti a 16 bit e architetture ibride a 32 bit, come nel caso di Windows 95, errori banali negli installer potevano compromettere la stabilità dell’intero sistema. Molti componenti software comuni erano distribuiti insieme alle applicazioni e Microsoft si trovò a fronteggiare una diffusione incontrollata di versioni incompatibili delle librerie di base.

La soluzione adottata non si limitò a una semplice validazione preventiva, ma introdusse un meccanismo di ripristino retroattivo che anticipa concetti oggi centrali.

Lo spiega Raymond Chen, storico ingegnere software di Microsoft e autore del blog The Old New Thing, noto per spiegare in modo approfondito il funzionamento interno e le scelte progettuali di Windows. Riportando alla luce tante curiosità poco note sui sistemi operativi made-in-Redmond.

Il problema strutturale degli installer negli anni ’90

Le applicazioni per Windows 3.1 e ambienti precedenti includevano spesso copie locali di DLL e componenti condivisi.

La linea guida ufficiale prevedeva un confronto tra versioni tramite il campo version number, con sovrascrittura consentita solo in presenza di una versione più recente. In teoria, la compatibilità retroattiva garantiva che un componente aggiornato funzionasse anche con software più datato.

La realtà operativa risultava molto diversa. Numerosi installer ignoravano deliberatamente il controllo versione e sovrascrivevano qualsiasi file presente. Il passaggio a Windows 95 aggravò il problema: versioni più vecchie provenienti da Windows 3.1 sostituivano componenti aggiornati, introducendo incompatibilità e provocando crash.

Una soluzione apparentemente ovvia consisteva nell’impedire la sovrascrittura dei file di sistema: Chen ricorda però che i test mostrarono effetti collaterali difficili da gestire. Alcuni installer interpretavano il blocco come errore critico e interrompevano l’installazione, mentre altri chiedevano all’utente decisioni tecniche per molti di difficile interpretazione.

Alcuni software tentavano strategie alternative, come il riavvio del sistema per eseguire una sostituzione tramite script batch.

Il meccanismo di autoriparazione di Windows 95

La risposta adottata da Microsoft fu, per quell’epoca, assolutamente fuori dagli schemi.

Windows 95 consentiva agli installer di operare liberamente, per poi intervenire a posteriori. Il sistema manteneva una copia di sicurezza dei file critici all’interno della directory nascosta C:\Windows\SYSBCKUP.

Al termine di ogni installazione, il sistema eseguiva una verifica automatica. Se rilevava che un file protetto era stato sostituito, confrontava la versione del nuovo file con quella archiviata. In presenza di un downgrade, ripristinava la copia corretta. Se invece la nuova versione risultava più recente, aggiornava il backup per riflettere lo stato corrente.

Quella logica introduceva un comportamento interessante: il sistema non cercava di impedire l’errore, ma lo correggeva dopo che si era verificato. Una scelta pragmatica, coerente con un contesto in cui il controllo sugli installer di terze parti era limitato.

Il meccanismo di verifica post-installazione operava in modo asincrono rispetto al processo di setup. Ciò riduceva l’impatto sull’esperienza utente, ma introduceva una finestra temporale in cui il sistema poteva trovarsi in uno stato inconsistente. Inoltre, il controllo si applicava solo a un insieme definito di file considerati critici.

Un ulteriore limite era legato alla mancanza di un controllo centralizzato delle dipendenze, cioè dei componenti software da cui un programma dipende per funzionare correttamente. Il sistema si basava unicamente sul confronto dei numeri di versione, senza verificare la compatibilità ABI (Application Binary Interface, ovvero l’insieme delle regole che garantiscono che componenti compilati separatamente possano comunicare tra loro) né considerare le dipendenze indirette, cioè quelle richieste a loro volta da altri componenti. Di conseguenza, in presenza di versioni numerate in modo incoerente o contenenti modifiche non retrocompatibili (cioè incompatibili con versioni precedenti), il sistema poteva comunque andare incontro a malfunzionamenti.

L’evoluzione verso modelli più robusti

Le criticità emerse in Windows 95 (oggi può essere provato con un’app dedicata, senza installazione) contribuirono allo sviluppo di soluzioni più strutturate nelle versioni successive di Windows.

Strumenti come Windows File Protection in Windows 2000 e Windows XP introdussero un monitoraggio continuo dei file di sistema, mentre tecnologie come Side-by-Side Assemblies ridussero la dipendenza da DLL condivise, consentendo la coesistenza di più versioni.

Parallelamente, Microsoft iniziò a imporre vincoli più rigidi agli installer, favorendo l’uso di API dedicate come VerInstallFile per la gestione sicura delle sostituzioni. Per alcuni componenti critici si svilupparono installer “ad hoc”, impedendo modifiche dirette e centralizzando la logica di aggiornamento.

Una lezione ancora attuale nella sicurezza del software

Il comportamento osservato in Windows 95 anticipa pratiche moderne di self-healing e resilienza applicativa. Consentire operazioni potenzialmente dannose e intervenire successivamente può risultare più efficace rispetto a un blocco rigido, soprattutto in ambienti eterogenei e poco controllabili.

La gestione delle versioni, il controllo delle dipendenze e la protezione dei file critici restano elementi centrali anche nei sistemi contemporanei. Tecnologie come containerizzazione e gestione dei pacchetti hanno raffinato questi concetti, ma il principio di base rimane invariato: il controllo totale dell’ambiente di esecuzione è difficile, mentre la capacità di correggere gli errori in modo automatico rappresenta un vantaggio concreto.