Sto vedendo da un po’ di tempo post nostalgici che mostrano schermate di Windows 95 o foto di clienti entusiasti col pacchetto d’installazione in mano. La prima volta ho pensato che fosse buffo, poi mi sono ricordato che ormai sono passati 30 anni dalla sua pubblicazione e che quindi molti informatici di oggi sono semplicemente troppo giovani per averne vissuto il lancio, così ho pensato di raccontarlo un pochino. Andiamo quindi a scoprire perché l’ho definito “accrocco”.

A metà anni ’90 già si intuiva che l’informatizzazione era il futuro, ma la tecnologia disponibile si sposava male con l’idea che i prossimi anni 2000 sarebbero stati anni iper-tecnologici. Nel famoso dibattito LINUX is obsolete, Andrew Tanenbaum, informatico di fama internazionale, ipotizzava che in pochi anni si sarebbero diffusi i processori RISC, considerati allora molto promettenti, ma diffusi solo negli ultimi anni grazie all’architettura ARM, quella dei cellulari. Le cose sono andate diversamente: l’accoppiata PC IBM + MS-DOS ai suoi tempi si rivelò così vincente che stabilì uno standard de facto per tutti gli anni a venire. In pratica, la maggior parte dei computer in circolazione negli anni ’90 erano basati sulla stessa architettura, coi suoi limiti che la rendevano più economica di altre, e con MS-DOS, che però era un sistema a riga di comando e quindi considerato ostico per molti potenziali utenti, nonché obsoleto, dato che sfruttava molto poco dei processori x86 di allora: niente multitasking, architettura a 16 bit ed esecuzione senza protezione della memoria né memoria virtuale (modalità reale). Microsoft aveva già messo in atto alcune strategie per superare questi limiti. Per cominciare, lanciò Windows, che inizialmente era solo un ambiente grafico che girava su MS-DOS e ne conservava molti limiti, poi sperimentò Windows NT, primo vero sistema operativo grafico a 32 bit, che però richiedeva macchine potenti e costose per girare.

Microsoft rischiava a lungo andare di perdere terreno rispetto ad altre aziende, come la Apple che vendeva computer pronti all’uso dotati di un’interfaccia grafica intuitiva. Aveva bisogno di un prodotto moderno che mantenesse la compatibilità coi vecchi programmi, girasse con poca memoria sui processori più diffusi (minimo 80386 e 80486) e offrisse per la prima volta il Plug & Play, cioè la capacità (oggi data per scontata) di riconoscere automaticamente l’hardware connesso riducendo la configurazione manuale al minimo.

Il problema venne risolto riutilizzando varie parti a 16 bit di MS-DOS e Windows 3.1, integrando con alcune altre a 32 bit scritte ad-hoc. Vediamo nel dettaglio:

Windows 95 si avviava ancora tramite MS-DOS 7.0, che forniva:

• IO.SYS: inizializza il sistema e carica i driver base.
• MSDOS.SYS: ristrutturato come file di configurazione, non più contenente codice.
• COMMAND.COM: shell testuale DOS, ancora disponibile per compatibilità.
• CONFIG.SYS / AUTOEXEC.BAT: supportati ma non più essenziali; servono per caricare driver in modalità reale.

La presenza di MS-DOS 7 permetteva la compatibilità piena con le vecchie applicazioni per DOS, ancora diffusissime, che potevano essere lanciate a tutto schermo nel proprio ambiente nativo com’era sempre stato fatto. Era in particolare utile per i giochi che bypassavano il sistema operativo accedendo direttamente all’hardware e che non avrebbero avuto le stesse prestazioni in una finestrella dell’ambiente grafico. Per gli utenti che lavoravano soprattutto con programmi per DOS c’era la possibilità di configurare l’avvio in modalità MS-DOS e lasciare l’avvio dell’ambiente grafico al comando WIN, come con Windows 3.1.

Quando il sistema era avviato in modalità grafica, il DOS poteva comunque essere emulato con la classica applicazione “Prompt dei comandi”.

Molti moduli a 16 bit di Windows 3.x sono stati mantenuti:

• GDI e USER (in parte): alcune API grafiche e di gestione della GUI sono ancora a 16 bit.
• Sottosistema Win16: per eseguire applicazioni Windows 3.x.
• Driver a 16 bit: stampanti, modem, schede video, ecc.
• Librerie DLL condivise: come COMMDLG.DLL, SHELL.DLL, TOOLHELP.DLL.

Questo permetteva di eseguire le applicazioni di Windows 3.x in modo nativo, senza emulazioni, e di riutilizzare almeno in parte i driver per periferiche esistenti.
In questo modo, inoltre, il sistema grafico era più leggero e quindi adatto a girare su molti dei computer già presenti nelle case e negli uffici o comunque dal prezzo più accessibile, strategia che sappiamo essere vincente ancor più alla luce del disastro di Windows Vista di anni dopo, che richiedeva macchine ben più potendi della media presente in circolazione.

Accanto a tutto ciò, furono aggiunti:

• VMM32.VXD: Virtual Machine Manager, che gestisce multitasking, memoria virtuale, protezione.
• Kernel32.dll: API di base per processi, file, memoria.
• User32.dll / Gdi32.dll: versioni a 32 bit delle API grafiche, che coesistono con le controparti a 16 bit.
• Explorer.exe: nuova shell grafica con desktop, taskbar e menu Start.
• Registro di sistema (SYSTEM.DAT / USER.DAT): sostituisce WIN.INI e SYSTEM.INI per le configurazioni.

Queste componenti permettevano di eseguire le applicazioni a 32 bit, che sarebbero diventate lo standard negli anni a venire man mano che i produttori aggiornavano o riscrivevano i propri programmi.

Ci fu inoltre una grande novità: DirectX. Si tratta di una serie di librerie che favoriscono lo sviluppo di videogiochi sfruttando tutte le potenzialità dell’hardware. Le prime versioni di Windows infatti erano pensate per lavorare, ma il sistema era troppo rigido perché si potessero sviluppare giochi con la grafica e la fluidità di quelli che giravano in DOS. I giochi per Windows 3.1 sono infatti molto semplici e con grafica 2D. Per evitare che i produttori di giochi ignorassero la nuova piattaforma spingendo i loro clienti su altre, venne dunque l’idea di creare delle apposite librerie per superare questi problemi. L’idea fu vincente e infatti le DirectX vivono ancora oggi.

E fin qui pare che tutto fosse rose e fiori: un sistema che offriva compatibilità nativa a ben tre sistemi, DOS, Win16 e Win32, ma nella realtà non era proprio così:

• Un software molto complesso ed eterogeneo, con componenti così diverse che devono comunicare fra loro è più soggetto a bug;
• L’ambiente 16 bit, per compatiblità, non poteva fornire una completa separazione dei processi, ed in particolare una completa protezione della memoria come in modalità 32 bit. Significa che un’applicazione o un driver a 16 bit malfunzionante poteva finire per sovrascrivere la memoria di un’altra o una struttura di sistema mandandolo completamente in crash. Applicazioni malevoli inoltre potevano letteralmente rubare dati alle altre;
• Alcune parti del sistema avevano strutture di memoria in comune, col risultato che un bug in una parte poteva bloccarne un’altra;
• Windows 95 aveva una politica permissiva sui driver, anche in virtù del fatto che supportava i vecchi a 16 bit, ma un driver scritto male può bloccare l’intero sistema, specialmente se non adeguatamente protetto;
• Le applicazioni a 16 bit giravano all’interno dello stesso thread, nel quale era implementato il multitasking cooperativo come su Windows 3.1. Nel multitasking cooperativo l’applicazione deve cedere volontariamente il controllo al sistema di tanto in tanto. Se un’applicazione si blocca e non cede il controllo, si bloccano anche tutte le altre.

Ne venne fuori un sistema bello da vedere, col caratteristico pulsante “Start” che usiamo ancora oggi, e che traghettava gli utenti verso la diffusione di massa dell’informatica e che aveva costi economici ridotti sia perché supportava hardware vecchio sia perché non richiedeva programmi nuovi, ma che nel complesso era fragile e poco sicuro: un accrocco, insomma. Il Plug and Play inoltre spesso si limitava a rilevare che era stata collegata una periferica nuova, mentre era richiesta ancora una certa competenza per configurarla, specialmente se vecchia. Questo perché l’hardware stesso era ancora pensato per essere configurato tramite deviatori fisici sulle schede e assegnazioni manuali di risorse, i driver erano su dischetto e non certo in qualche archivio online e andavano installati a mano, avendo cura di scegliere la versione giusta.

Nonostante i problemi fu un grande successo, che andò aumentando con Windows 98, che ne condivideva l’architettura ibrida. Il punto di forza dunque furono: un’interfaccia semplice da usare anche per i meno esperti; la multimedialità; la compatibilità con software esistente; la compatibilità con hardware datato.

Fatto curioso, Windows 95 aveva un leggero vantaggio teorico sul sistema Apple di allora (System fino alla versione 7, Mac OS poi), al quale mancava il multitasking preemptivo e la protezione della memoria, ma il sistema di casa Apple poteva vantare una maggiore stabilità per il fatto di essere progettato e ottimizzato per funzionare su un numero molto ristretto di macchine: i Macintosh di quegli anni.

Fu solo con Windows XP del 2001 che si abbandonò l’architettura ibrida di Windows 95 per passare completamente all’architettura di Windows NT, che si è evoluto in Windows 2000, XP, Vista, e così via fino ad arrivare all’attuale versione 11. Windows NT forniva un sistema completamente a 32 bit, stabile, sicuro e con la stesso aspetto di Windows 95, ma richiedeva hardware più potente ed era meno orientato alla multimedialità. Mancava completamente DirectX, per esempio, trattandosi di un sistema destinato alle aziende. Il supporto alle applicazioni a 16 bit era invece emulato e non nativo, cosa che le rendeva più sicure, ma anche più pesanti e potenzialmente inclini ad andare in crash se facevano uso di tecniche di programmazione poco comuni. Il supporto per le applicazioni a 16 bit è ufficialmente finito con l’introduzione dei sistemi a 64 bit, ma è possibile reintrodurlo con software di terze parti come DosBox e WineWDM.

Ora conoscete un po’ meglio la storia ed alcuni dettagli tecnici. Io che all’epoca ero bambino m’innamorai di Windows 95 dopo averne visto un dimostrativo chiamato “Windows 95 Virtual Tour” ed insstetti tanto per averlo sul nostro 486 di casa. Ironicamente, tempo dopo incominciai a sentire la mancaza del prompt di MS-DOS, ma ormai la storia aveva già deciso in favore dei sistemi grafici.