Windows 95 escondia pequeno segredo que acelerava reinicialização: motivo estava em arquitetura caótica

Se você usou outros sistemas operacionais antes do Windows 95, é difícil não se lembrar da sensação de estar diante de algo completamente novo. Essa proposta introduziu elementos que hoje consideramos indispensáveis, como o menu Iniciar, a barra de tarefas e o Plug and Play, e o fez numa época em que inicializar um PC era quase um pequeno ritual. Mas por baixo dessa interface familiar havia uma arquitetura complexa, resultado da coexistência forçada entre o legado do DOS, o Windows de 16 bits e as primeiras camadas de 32 bits. Esse design, tão deselegante quanto eficaz, deu origem a comportamentos inesperados que ainda surpreendem hoje.

Poucos usuários sabiam que o Windows 95 escondia uma rota alternativa à reinicialização clássica. Bastava manter pressionada a tecla Shift durante o processo iniciado pela interface gráfica para que o sistema exibisse o aviso "O Windows está reiniciando", em vez de seguir o caminho de uma reinicialização a frio, como descrito por Raymond Chen. A diferença não era espetacular, mas era perceptível numa época em que cada minuto da inicialização contava. Esse pequeno gesto ativava um mecanismo interno projetado para evitar, sempre que possível, a reinicialização completa.

O atalho que não reiniciava completamente

Por trás desse comportamento, havia uma decisão técnica precisa. Chen detalha que o Windows 95 utilizava um parâmetro chamado EW_RESTARTWINDOWS ao invocar a antiga função ExitWindows, ainda de 16 bits. Com essa instrução, o sistema não ordenava uma reinicialização completa do computador, mas algo mais limitado: fechar o Windows e iniciá-lo novamente. O objetivo era economizar etapas, desde que a situação interna permitisse, embora essa otimização dependesse do correto funcionamento de todos os componentes.

Uma vez tomada essa rota alternativa, o processo seguia uma sequência muito específica. Primeiro, o kernel do Windows de 16 bits era fechado. Em seguida, o gerenciador de memória virtual de 32 bits era desativado e o processador retornava ao modo real, o estado mais básico do sistema. Nesse ponto, o controle retornava ao win.com com um sinal especial que solicitava algo muito específico: iniciar o Windows novamente em modo protegido, sem passar por uma inicialização completa do computador.

Com o controle de volta ao win.com, a parte mais delicada do processo começava. O programa precisava simular uma inicialização limpa do Windows, como se tivesse acabado de ser executado do zero, o que envolvia, nas palavras de Chen, redefinir as opções da linha de comando e retornar algumas variáveis ​​globais aos seus valores originais. Embora o trabalho fosse em grande parte burocrático, era especialmente complexo porque se tratava do win.com, escrito em linguagem assembly. Não havia abstrações nem recursos modernos.

O ponto decisivo estava na memória. Quando o win.com era executado, como qualquer arquivo .com, ele recebia toda a memória convencional disponível. No entanto, ele liberava quase toda a memória além do seu próprio código para que o Windows pudesse carregar um grande bloco contíguo ao entrar no modo protegido. Se, durante a sessão, um programa reservasse memória dentro do espaço liberado pelo win.com, a memória ficava fragmentada. Nesse cenário, o win.com não conseguia mais recriar o mapa original esperado e, como explica Chen, era forçado a abandonar a reinicialização rápida e recorrer a uma reinicialização completa.

Quando tudo se encaixou, o processo continuou sem retrocessos. O win.com foi direto para o código responsável por inicializar o Windows em modo protegido, recriando o gerenciador de máquinas virtuais e elevando novamente as camadas de 32 bits. A partir daí, a interface gráfica carregava normalmente e o usuário retornava à área de trabalho. A diferença era sutil, mas real: o Windows não precisava reiniciar todo o sistema para chegar a esse ponto.

Esse tipo de atalho só era viável em um sistema construído com base em compatibilidade cruzada. O Windows 95 precisava coexistir com software DOS, programas Windows de 16 bits e aplicativos Win32, e essa mistura forçou a aceitação de soluções pouco elegantes, mas muito práticas. Os desenvolvedores até se aproveitaram dessa complexidade para introduzir otimizações ocultas que podiam acelerar a reinicialização, embora às vezes pudessem causar travamentos.

A obsessão por economizar memória levou a soluções muito criativas. Chen explica que, em linguagem assembly, era comum reciclar o código que não seria mais usado como se fosse memória livre. No win.com, os primeiros bytes do ponto de entrada eram reutilizados como uma variável global, sob a premissa de que esse código seria executado apenas uma vez. Como a reinicialização rápida não retornava a esse ponto inicial, era possível usar esse atalho sem afetar o processo.

Esse atalho também mostrou suas falhas. Chen lembra que alguns usuários detectaram travamentos após realizar várias reinicializações rápidas consecutivas, algo que ele não conseguiu reproduzir de forma consistente. Sua hipótese é que algum controlador não reiniciava corretamente, deixando o sistema em um estado estranho, e essa estranheza acabou causando problemas posteriormente. Não é surpresa que esse tipo de comportamento não tenha sido apresentado como um recurso documentado, mas resume bem o espírito do Windows 95: engenhoso, ambicioso e cheio de concessões.

Imagens | Microsoft