Windows ConfidentialWindows 95 Unplugged
Raymond Chen
Sebbene i programmi a 32 bit per Windows® 95 fossero in grado di utilizzare un compilatore standard a 32 bit e programmi a 16 bit un compilatore standard a 16 bit, per lo stesso Windows 95 è stato necessario un compilatore speciale, in grado di interpretare entrambi i mondi a 32 e 16 bit e di colmare tale lacuna. Per Windows 95 è stato inoltre necessario un linker personalizzato che capisse come unire questi due tipi di codice e un linker personalizzato per VxDs (il formato driver per Windows 95).
Il team Windows 95 si è affidato al reparto linguaggi e strumenti per fornire compilatori e linker per applicazioni specifiche. Sono sicuro che il reparto linguaggi ha trovato la seguente richiesta alquanto strana: "Vorresti un compilatore che faccia X, Y, e Z e che sia utilizzato per compilare soltanto due DLL per tutta la sua durata"? È vero. Ma questi erano, dopotutto, due DLL piuttosto importanti.
Malgrado l'assurdità apparente della richiesta, il reparto linguaggi e strumenti è riuscito nell'intento, facendo diventare il compilatore e il linker parti altamente specializzate del processo di generazione di Windows 95. Certo, il compilatore non era stato completato alla sua prima uscita. Il team di Windows ha ricevuto una versione preliminare e in seguito aggiornamenti periodici man mano che nuove ottimizzazioni erano implementate e gli errori riparati.
Un giorno la generazione Windows 95 rallentò inaspettatamente. Un file che solitamente utilizzava pochi secondi per creare un collegamento improvvisamente impiegava minuti. Il file veniva tuttavia generato correttamente, ma impiegava molto tempo. E non era un problema che colpiva solamente un computer di uno sviluppatore: l'intero team venne colpito. Il nostro codice ha scoperto improvvisamente un caso patologico nel linker? Ci siamo imbattuti in un errore del linker?
Dopo alcuni tentativi di debug, abbiamo identificato la sorgente del problema. La versione più recente del linker conteneva del codice diagnostico che il reparto linguaggi aveva dimenticato di rimuovere prima di dare il codice al team di Windows. Questo codice diagnostico ha registrato il suo output in un file memorizzato in un computer nell'ufficio di un membro del team del compilatore. E il computer in quel momento si è spento. (Questo riporta a Leslie Lamport, famoso per aver descritto un sistema distribuito come uno in cui non è possibile concludere alcun lavoro perché un computer di cui non hai mai sentito parlare è spento).
Quella versione del linker aveva lavorato tranquillamente per settimane. Ogni volta che qualcuno tentava di collegare un VxD durante la generazione di Windows 95, veniva eseguito un aggiornamento del file posto in quel computer dello sviluppatore. Finché quel computer è rimasto acceso e connesso alla rete, nessuno ha mai notato nulla. Ma un giorno quel computer si è spento e tutto è estremamente rallentato.
Una volta identificato il problema, il team del compilatore non ha impiegato molto tempo a fornire al team di Windows una patch che rimuovesse il codice diagnostico dal linker.
Esistono diversi punti salienti di questa storia, a seconda di chi la racconta. Quando racconto la mia storia, il punto saliente è, "E quello sviluppatore del compilatore trasferitosi in seguito nel team di Windows è finito per diventare il mio capo". Ho spesso avuto il piacere di raccontare nuovamente questa storia come una lieve presa in giro.
Tuttavia, se fosse il mio capo a raccontare questa storia, il punto saliente sarebbe piuttosto diverso: "E il risultato è che non ho nemmeno scritto io quel codice diagnostico. È stato uno dei miei colleghi che ha deciso di riempire il mio computer con le informazioni diagnostiche, al posto del suo!"
Sul sito Web di Raymond Chen, The Old New Thing, così come nell'omonimo libro, vengono illustrate la storia di Windows e la programmazione con Win32. Nel suo DNA vi è codice morto.