DOOM Roda por Mais de Dois Anos e Trava por Bug de 1997

No panteão dos gigantes da tecnologia, poucos nomes ecoam com a mesma reverência de DOOM. É um software que já rodou em calculadoras, testes de gravidez e tratores. Mas toda lenda tem seu limite, e recentemente, descobrimos o de DOOM: aproximadamente dois anos e meio de execução contínua. Em um experimento que mistura arqueologia digital e um teste de resistência quase poético, uma cópia do jogo travou em um antigo dispositivo de 2003, não por falha de hardware, mas por um fantasma no código original de 1997.

O feito foi relatado por Minki, administrador do site LenOwO, que decidiu colocar um aparelho ASUS MyPal A620 para uma única e longa tarefa: rodar WinDOOM, uma versão baseada no código-fonte original do jogo. O dispositivo, um PDA de 2003 equipado com Windows Mobile e um processador Intel XScale ARMv5, foi mantido ligado com uma fonte de energia estável, marcando o tempo incansavelmente por mais de 900 dias. O resultado foi um crash inevitável, uma falha programada pelo próprio tempo.

A Arqueologia de um Crash Anunciado

Imagine a cena: em algum lugar, um pequeno dispositivo de uma era pré-iPhone, com sua tela resistiva e design robusto, executa a mesma tarefa dia após dia. O ASUS MyPal A620 é uma verdadeira relíquia, um sobrevivente de uma época em que a computação móvel ainda engatinhava. Mantê-lo funcional e alimentado por tanto tempo já é, por si só, um ato de dedicação.

O objetivo do experimento era simples, quase meditativo: deixar DOOM rodar. O jogo foi deixado no seu “modo de atração” (attract mode), onde demos automáticas são exibidas na tela inicial para atrair jogadores. É a mesma tela que muitos de nós vimos em fliperamas ou ao iniciar o jogo no PC. O que ninguém imaginava é que essa tela de descanso seria a chave para o colapso do sistema, graças a uma pequena variável com um grande problema de contagem.

Anatomia do Bug: A Tirania do Contador 'gametic'

Para entender o que aconteceu, precisamos descer às catacumbas do código de DOOM. A fonte do problema é uma variável chamada gametic. Segundo o relato, que se baseia na análise do código original, essa variável é o coração do motor de tempo do jogo. Ela funciona como um metrônomo interno, garantindo que a lógica do jogo avance de forma consistente, independentemente do quão rápido ou lento o computador consiga renderizar os gráficos.

O problema reside em como essa variável foi construída e como ela se comporta. Aqui estão os detalhes técnicos que selaram o destino do experimento:

• O Contador Implacável: A variável gametic é incrementada 35 vezes a cada segundo (35 Hz). É o tique-taque que move o universo de DOOM, controlando animações, movimento de inimigos e eventos no jogo.
• O Limite de 32 Bits: Na programação original de 1997, gametic foi definida como um inteiro de 32 bits com sinal (signed 32-bit integer). Na prática, isso significa que ela pode armazenar um valor máximo de 2.147.483.647. Após esse número, ocorre um “overflow”, e o contador vira para um valor negativo, causando o caos no sistema.
• O Loop da Perdição: O detalhe fatal é que, durante o modo de demonstração na tela inicial, o contador gametic nunca é reiniciado. A cada nova demo, ele continua de onde parou, acumulando tiques sem parar.

Ao manter o jogo rodando por dois anos e meio, o contador gametic finalmente atingiu seu limite máximo. No momento em que o valor 2.147.483.647 foi ultrapassado, ele “virou” para -2.147.483.648. A lógica do jogo, que não esperava viajar no tempo para um valor negativo, simplesmente quebrou, resultando no travamento completo do WinDOOM.

Um Fantasma na Máquina de 1997

Este evento é mais do que uma curiosidade técnica; é um testemunho da longevidade do software e das decisões de programação de décadas passadas. Quando John Carmack e a equipe da id Software escreveram o código de DOOM, é improvável que tenham imaginado alguém deixando o jogo rodar continuamente por mais de dois anos. Naquela época, um inteiro de 32 bits parecia mais do que suficiente para qualquer contador.

Esse bug não é uma falha no sentido tradicional, mas sim um limite matemático inerente à tecnologia da época. É um lembrete de que todo código carrega as marcas e as limitações de seu tempo. O fato de que o hardware de 2003 e o software de 1997 funcionaram em harmonia por tanto tempo antes de atingir esse limite é, na verdade, uma prova da robustez de ambos.

No fim, a maratona de DOOM no ASUS MyPal A620 terminou de forma previsível para os programadores, mas fascinante para todos nós. Foi uma bela demonstração de um conceito clássico da ciência da computação, o overflow de inteiros, se desenrolando em câmera lenta ao longo de 900 dias. O Doom Slayer pode ser imbatível contra as hordas do inferno, mas nem ele pode derrotar a matemática.