Windows ConfidentialWindows 95 não-conectado

Raymond Chen

Embora os programas de 32 bits para Windows® 95 pudessem usar o compilador médio de 32 bits e os programas de 16 bits pudessem usar o compilador médio de 16 bits, o próprio Windows 95 precisava de um compilador especial, um que compreendesse os mundos de 32 e de 16 bits e pudesse preencher essa lacuna. O Windows 95 também precisava de um vinculador personalizado que compreendesse como colar esses dois tipos de código, além de um vinculador personalizado para VxDs (o formato de driver do Windows 95).

A equipe do Windows 95 dependia da divisão de linguagens e de ferramentas para fornecer esses compiladores e vinculadores especiais. Tenho certeza de que a divisão de linguagens achou estranha esta solicitação: "Você quer que a gente escreva um compilador que faça X, Y e Z e que será usado para compilar apenas duas DLLs em todo o tempo de vida?" Verdade. Mas, afinal, elas eram duas DLLs muito importantes.

Apesar do aparente absurdo da solicitação, a divisão de linguagens e ferramentas conseguiu, e o compilador e o vinculador altamente especializados se tornaram parte do processo de compilação do Windows 95. É claro que o compilador não estava totalmente pronto desde o começo. A equipe do Windows recebeu uma versão preliminar, e atualizações periódicas como novas otimizações foram implementadas e os bugs, corrigidos.

Um dia, a compilação do Windows 95 parou inesperadamente. Um arquivo que costumava demorar segundos para ser vinculado passou a demorar minutos. Mesmo assim, o arquivo foi gerado com êxito, mas demorou uma eternidade. E isso não foi apenas na máquina do desenvolvedor – o problema atingiu todos da equipe inteira. O nosso código acabou encontrando algum caso patológico no vinculador? Nos deparamos com um bug do vinculador?

Depois de algumas depurações, identificamos a origem do problema. A versão mais recente do vinculador apresentava um código de diagnóstico que o pessoal de linguagens se esqueceu de remover antes de entregar o código à equipe do Windows. Essa ferramenta de diagnóstico gravou em log a saída para um arquivo armazenado em um computador presente no escritório de um membro da equipe do compilador. E o computador acabou sendo desligado. (Isso me lembra Leslie Lamport, famoso por descrever um sistema distribuído como sendo o único no qual não é possível realizar nenhum trabalho porque um computador do qual você nunca ouviu falar está desligado.)

Essa versão do vinculador permaneceu em execução tranqüilamente durante algumas semanas. Sempre que alguém tentava vincular a um VxD durante a compilação do Windows 95, era feita uma atualização no arquivo do computador do desenvolvedor. Enquanto esse computador permanecia ligado e conectado à rede, ninguém sequer notava. Mas um dia esse computador foi desligado, e tudo parou.

Uma vez identificado o problema, não demorou muito para que o pessoal do compilador oferecesse à equipe do Windows um patch que removia o código de diagnóstico do vinculador.

Há linhas de visão diferentes nessa história, dependendo de quem a conta. Quando eu conto, a linha é: "e esse desenvolvedor do compilador mais tarde se transferiu para a equipe do Windows e acabou virando o meu chefe". Gosto sempre de recontar essa história como uma forma de incentivo.

No entanto, quando o meu chefe conta a história, a linha é bem diferente: "E eu sequer escrevi aquele código de diagnóstico. Foi um dos meus colegas que, em vez de preencher seu próprio computador com informações de diagnóstico, preencheu o meu!"

O site do Raymond Chen, The Old New Thing, e o livro homônimo tratam do histórico do Windows e da programação Win32. Seu DNA está cheio de códigos inativos.