O segredo técnico por trás de Quake: como um único executável rodava TCP/IP no DOS e no Windows 95

Quando Quake foi lançado em 1996, o jogo marcou a transição para gráficos 3D completos e trouxe um dos primeiros modos multiplayer via TCP/IP, algo inédito em larga escala.

Mas um detalhe técnico pouco discutido permanece impressionante até hoje: o mesmo executável funcionava tanto no DOS quanto no Windows 95, dois ambientes com arquiteturas e modelos de memória completamente distintos.

Enquanto muitos games da época precisavam de versões separadas para cada sistema, Quake rodava em ambos e ainda conseguia usar a pilha de rede moderna do Windows.

Um novo estudo detalhado de Fabien Sanglard explica como a id Software fez isso funcionar.

Por que Quake precisava ser um híbrido único

A metade dos anos 90 foi marcada por uma transição acelerada: surgiram GPUs 3D, o Windows 95 ganhou terreno e a internet começou a chegar às casas.

Os estúdios precisavam decidir entre continuar no DOS (ainda dominante entre jogadores) ou mover tudo para a nova plataforma.

A id queria os dois públicos, sem fragmentar o código. Além disso, buscava integrar multiplayer remoto de verdade, indo além das LANs e modems ponto a ponto. Para isso, era indispensável compatibilidade com TCP/IP, que o Windows 95 oferecia nativamente.

Mas o DOS não tinha nada parecido. E sua estrutura limitava memória, multitarefa e acesso à rede.

DPMI e a gambiarra necessária para fazer o DOS competir com o Windows

Para contornar as limitações do DOS, os jogos passaram a usar DPMI (DOS Protected Mode Interface), um conjunto de extensões que funcionava quase como um micro-kernel.

Ferramentas como DOS/4GW e CWSDPMI eram comuns em jogos como Doom, Mortal Kombat 3 e Fallout. Só que, por padrão, cada jogo dependia de um único servidor DPMI, e as implementações variavam entre fabricantes.

A id resolveu migrar para o compilador open source djgpp e pediu ao time responsável que adaptasse seu cliente DPMI para conversar tanto com o servidor do CWSDPMI quanto com o DPMI embutido no Windows 95. A compatibilidade cruzada era incomum e imprevisível.

Como descreveu o engenheiro Raymond Chen, da Microsoft:

O fato de programas funcionarem sob um extensor diferente daquele para o qual foram escritos é algo que surpreende ou parece óbvio, dependendo do seu ponto de vista

Esse passo foi fundamental: significava que o Quake rodando no DOS, quando executado dentro do ambiente “quase DOS” do Windows 95, ainda conseguia acessar recursos do sistema moderno.

O problema do TCP/IP: Winsock no Windows e nada no DOS

Mesmo com o DPMI funcionando, a id precisava conectar o jogo à internet. No Windows, era simples: bastava usar Winsock, a interface de sockets criada pela Microsoft. No DOS, não havia Winsock nativo.

A solução veio por meio de uma parceria com a Mpath Interactive, empresa responsável pelo serviço de matchmaking Mplayer, uma das primeiras plataformas a listar partidas online em tempo real.

O pacote da Mpath incluía dois componentes importantes:

• Gizmo, o browser de partidas
• Chunnel, responsável por intermediar chamadas de rede entre o jogo e o Windows

E, mais importante, fornecia o dispositivo virtual genvxd.dll, capaz de traduzir chamadas de rede estilo BSD sockets (usadas pelo Quake) para o Winsock 95.

Assim, mesmo no DOS, o jogo conseguia se comunicar com a API de rede moderna, desde que rodasse dentro do ambiente híbrido do Windows.

Como o executável único funcionava na prática

O executável principal chamava dinamicamente:

• quake.exe no ambiente DOS
• quakeud.exe no Windows 95
• A DLL de rede correta era carregada dependendo do sistema
• O genvxd.vxd fazia a ponte entre as camadas

Essa engenharia permitia:

• Executar o mesmo binário
• Usar TCP/IP real
• Abrir conexões com servidores remotos
• Conversar com a pilha Winsock mesmo em ambiente DOS
• Integrar o browser de partidas do Mplayer

O diagrama técnico publicado por Sanglard mostra a complexidade dessa arquitetura, que envolvia drivers virtuais, extensores de memória, a pilha TCP/IP do Windows e um conjunto de hacks cuidadosamente montados.

A engenharia escondida: detalhes inéditos do código e ferramentas que permitiram o híbrido

Como vimos, um dos pontos mais marcantes foi a troca do compilador Watcom, usado em Doom, pela ferramenta djgpp, um port do GCC que permitia compilar Quake também em servidores Alpha.

O uso do djgpp habilitou o jogo a rodar com o go32, um cliente DPMI embutido no executável.

Tal escolha possibilitou que Quake conversasse tanto com o servidor DPMI do CWSDPMI quanto com a implementação do próprio Windows 95, algo que exigiu ajustes específicos dos engenheiros do djgpp.

A citação do engenheiro Raymond Chen, da Microsoft, sintetiza bem o espanto técnico que isso causou na época:

O cliente achava que estava usando o extensor incluído no jogo, mas na verdade estava falando com o DPMI do Windows. O fato de isso funcionar é algo completamente surpreendente ou totalmente óbvio, dependendo do seu ponto de vista

Outro aspecto inédito é a quantidade de arquivos que compunham o pacote do jogo. Apesar do caos aparente, apenas quatro eram essenciais para rodar no DOS: quake.exe, config.cfg, pak0.pak e cwsdpmi.exe.

Tudo o que ia além disso existia para sustentar recursos de rede, matchmaking ou compatibilidade entre sistemas. A presença de executáveis como qlaunch.exe, drivers como mgenvxd.vxd, bibliotecas como genvxd.dll e ponte de rede como quakeudp.dll revela a complexidade de integrar TCP/IP a um jogo originalmente desenhado para o DOS real-mode.

Os componentes eram necessários porque o DOS praticamente não tinha suporte nativo a rede moderna. Para habilitar IPX, Quake carregava um TSR que falava diretamente com o driver da placa de rede. Para TCP/IP, a situação era ainda mais limitante.

A única opção viável era usar o TSR BWNFS, vendido por US$ 395 em 1996, valor equivalente a US$ 830 em 2025. Por isso, quase ninguém jogava Quake em TCP/IP pelo DOS puro.

Grande parte do avanço veio da parceria com a Mpath Interactive, criadora do Mplayer. Ela forneceu a camada de matchmaking e também a ponte que permitiu que o executável DOS conversasse com o Winsock do Windows 95.

A ponte envolvia o uso de um dispositivo virtual (VxD) chamado GENVXD.VXD, que registrava interrupções específicas e fazia a tradução das chamadas BSD sockets para o ambiente Win32.

Os arquivos genvxd.dll e quakeudp.dll completavam esse pipeline, encaminhando chamadas, marshaling de dados e acesso ao wsock32.dll.

Um ex-funcionário da Mpath, Larry Hastings, relatou como a integração funcionava no dia a dia:

O Quake rodando no DOS usava o Chunnel para falar com a pilha TCP/IP do Windows. Licenciamos essa tecnologia para a id, e em troca o jogo entrou no Mplayer. Foi assim que o multiplayer via internet funcionou para muita gente em 1996

Além disso, Hastings relembrou um dos primeiros testes com a equipe da id Software:

Jogamos uma partida com eles via internet. Tim Willits nos destruía. Ele conhecia cada segredo dos mapas. Vi ele sair de uma porta secreta com um rocket launcher na mão. Seja ele não me viu ou eu morri logo depois

Os bastidores mostram o quanto Quake dependia de soluções externas, acordos técnicos e camadas de drivers proprietários que nunca foram liberados ao público.

Arquivos como mgenvxd.vxd, genvxd.dll e quakeudp.dll continham tecnologia patenteada da Mpath que não teve código-fonte aberto nem mesmo décadas depois. O lado DOS da API BSD chegou a ser liberado, mas a parte responsável por comunicar o executável com o Windows 95 permaneceu fechada.

A soma desses elementos revela que a façanha da id Software não foi apenas criar um executável híbrido, mas construir uma ponte elaborada entre mundos incompatíveis, envolvendo compiladores, DPMI de múltiplos fornecedores, TSRs de rede, drivers virtuais e software de matchmaking.

O ecossistema improvisado descreve o espírito de engenharia dos anos 90, quando soluções eram construídas em camadas e costuradas manualmente para alcançar resultados inéditos.

Leia também:

• Windows 95 faz aniversário de 30 anos
• Primeira cópia já feita do Windows 95 aparece em fotografia, em perfeitas condições
• Windows 95 ainda comanda máquina que organiza ovos na Alemanha

Por que isso ainda impressiona quase 30 anos depois

A solução da id Software foi uma maneira engenhosa de atravessar dois mundos incompatíveis, mantendo apenas uma base de código.

O movimento reduziu custo de desenvolvimento, ampliou compatibilidade e permitiu que o multiplayer TCP/IP de Quake tivesse alcance muito maior.

Enquanto outros estúdios criavam versões separadas, a id apostou em uma ponte técnica que antecipou um futuro de engines multiplataforma. Afinal, o executável híbrido de Quake revela como a id Software encarava engenharia: buscando caminhos pragmáticos para atingir o maior número de jogadores sem abrir mão de inovação.

A estrutura criada por John Carmack, John Cash e a equipe continua servindo de estudo para quem pesquisa compatibilidade entre sistemas, camadas de abstração e implementações antigas de rede até hoje.

Fonte: Fabien Sanglard