Resumo:
O Windows 11 já possui uma interface de usuário moderna, mecanismos de segurança avançados e recursos crescentes de inteligência artificial, mas no fundo do sistema operacional, a Microsoft ainda mantém alguns códigos da era do Windows 95. Surpreendentemente, esses códigos não são apenas deixados no sistema como arquivos históricos legados, mas ainda podem ser executados sob certas condições, fornecendo suporte de compatibilidade para alguns aplicativos que dependem de comportamento antigo de gerenciamento de memória.
No Windows 11 26H2, a Microsoft ainda mantém um mecanismo de reparo de compatibilidade de aplicativos chamado EmulateHeap. Ele permite que certos programas antigos usem código modelado a partir do gerenciador de memória do Windows 95 para evitar que esses programas travem devido a alterações na maneira como o Windows moderno gerencia a memória.
A história deste mecanismo remonta à década de 1990. Naquela época, um erro de programa foi exposto em um jogo clássico chamado “SimCity”. Em vez de simplesmente pedir aos desenvolvedores que consertassem o jogo, a Microsoft modificou diretamente o comportamento do Windows 95 para que o jogo pudesse continuar rodando. Desde então, a Microsoft tem usado um mecanismo de compatibilidade mais sistemático para ajudar outros softwares antigos com problemas semelhantes a continuarem funcionando em novas versões do Windows.
Essa história também revela um importante princípio de design do Windows há muito tempo: para um sistema operacional com um enorme ecossistema de software, manter programas antigos funcionando normalmente às vezes é mais importante do que limpar completamente o código histórico.
Erro de memória em "SimCity" solicita que a Microsoft modifique o sistema operacional
Para entender por que o EmulateHeap existe, você precisa primeiro entender um erro comum de programação: continuar lendo após liberar memória.
Quando o aplicativo está em execução, ele precisa solicitar memória do sistema operacional para salvar os dados. Quando os dados não forem mais necessários, o programa deverá liberar a memória correspondente para que o sistema possa realocá-los para outros usos.
Se um programa libera um bloco de memória, mas continua a ler dados dele, ocorre o chamado erro "use-after-free". Esta é uma falha típica de programação que pode fazer com que um programa leia dados inválidos, trave e até mesmo cause problemas de segurança em alguns casos.
Alguns programas nos primeiros ambientes do Windows contavam inesperadamente com esse comportamento errôneo.
De acordo com um artigo publicado em 2000 pelo cofundador do Stack Overflow e ex-engenheiro da Microsoft, Joel Spolsky, as primeiras versões do "SimCity" para Windows apresentavam problemas semelhantes. Jon Ross, o desenvolvedor desta versão, admitiu mais tarde que havia deixado acidentalmente um bug: o jogo continuaria a ler os dados originalmente armazenados ali após liberar a memória.
A razão pela qual esse problema não foi imediatamente exposto está relacionada ao método de gerenciamento de memória do Windows 3.x naquela época. Em certas circunstâncias, após o programa libertar a memória, os dados relevantes não são imediatamente substituídos por outros usos, pelo que quando o jogo continua a ler, ainda é possível obter o conteúdo original.
Em outras palavras, há um bug no próprio jogo, é apenas o comportamento do sistema operacional antigo que mascara o problema.
Quando a Microsoft desenvolveu o Windows 95, as coisas mudaram. O novo sistema adotou um mecanismo de gerenciamento de memória diferente, e o "SimCity" começou a funcionar mal na versão beta do Windows 95.
A Microsoft se deparou com duas opções: pedir aos desenvolvedores de jogos que corrigissem o programa ou deixar o sistema operacional continuar a tolerar o bug.
No final, a Microsoft escolheu a última opção.
Os engenheiros adicionaram um código de compatibilidade especificamente para "SimCity" ao Windows 95. Quando o sistema detecta que o jogo está sendo executado, ele muda para um modo especial de alocação de memória que não libera a memória associada imediatamente.
Dessa forma, mesmo que o jogo continue lendo os dados originais após liberar memória, é mais provável que obtenha os resultados esperados e evite travamentos.
Do ponto de vista da engenharia de software moderna, essa abordagem é bastante singular. Normalmente, os desenvolvedores de sistemas operacionais não desejam alterar o comportamento do sistema para encobrir erros de programação em software de terceiros. Mas o objectivo da Microsoft na altura era garantir que o novo sistema pudesse executar o software existente, em vez de forçar os utilizadores a abandonar os seus programas originais para actualizar o sistema operativo.
Esta decisão também se tornou um caso típico na história da compatibilidade do Windows.
De "SimCity" a EmulateHeap: o mecanismo de compatibilidade está se expandindo gradualmente
O tratamento especial para SimCity é apenas o começo.
À medida que o Windows evoluiu gradualmente, a Microsoft descobriu que não apenas este jogo, mas também outros aplicativos dependiam de alguns comportamentos especiais no mecanismo de gerenciamento de memória de versões mais antigas do Windows.
O engenheiro da Microsoft, Raymond Chen, explicou esse problema em uma coluna de tecnologia do Windows publicada em 2010. Alguns programas mais antigos continuarão a ler dados da memória depois de serem liberados, assumindo que os valores originais ainda existam.
Quando esses programas são executados em versões subsequentes do Windows, devido a alterações na alocação de memória e nos métodos de reciclagem, eles podem ler o conteúdo que foi substituído por outros dados e travar.
Se a Microsoft escrever um código especial para cada programa com esses problemas, não apenas o custo de manutenção será alto, mas também será difícil lidar com o número crescente de software antigo.
Como resultado, a Microsoft lançou um mecanismo de correção de compatibilidade chamado EmulateHeap.
Ao contrário do código específico do SimCity, o EmulateHeap fornece uma abordagem mais geral. Ele intercepta chamadas de aplicativos para interfaces relacionadas ao gerenciamento de memória e encaminha essas chamadas para uma implementação alternativa que emula o comportamento do Windows 95.
Isso envolve uma série de interfaces relacionadas ao gerenciamento de memória heap, incluindo HeapCreate, LocalLock e GlobalReAlloc. Ao adicionar uma camada de compatibilidade entre os aplicativos e os mecanismos subjacentes de gerenciamento de memória, o sistema pode permitir que certos programas legados continuem a funcionar da maneira que lhes é familiar.
O que é ainda mais surpreendente é que a Microsoft adotou uma implementação bastante simples.
De acordo com a explicação de Raymond Chen, os engenheiros da Microsoft copiaram diretamente o código-fonte do gerenciador de memória heap do Windows 95, recompilaram-no e adicionaram-no ao Windows Application Compatibility Framework.
Isso significa que um código de gerenciamento de memória muito importante do Windows 95 é de fato mantido na infra-estrutura moderna de compatibilidade do Windows.
No entanto, isso não significa que o Windows 11 esteja executando o gerenciador de memória do Windows 95.
EmulateHeap é um mecanismo de compatibilidade habilitado sob demanda. Somente quando um aplicativo específico estiver configurado para usar essa correção o código legado correspondente será carregado. Para programas comuns que não habilitam esse recurso, o Windows não mudará automaticamente para o método de gerenciamento de memória do Windows 95 devido a esse mecanismo de compatibilidade.
Além disso, EmulateHeap não é a mesma função que o código de compatibilidade escrito especificamente para "SimCity" pela Microsoft. Ambos refletem a filosofia de design da Microsoft de tentar manter o software antigo funcionando normalmente, mas seus métodos de resolução de problemas e seu escopo de aplicação são diferentes.
Como encontrar o EmulateHeap no Windows 11?
Para usuários que desejam entender o mecanismo de compatibilidade interna do Windows, a Microsoft fornece uma ferramenta chamada Administrador de Compatibilidade para visualizar correções de compatibilidade de aplicativos suportadas pelo sistema.
Essa ferramenta está incluída no Kit de Avaliação e Implantação do Windows (Windows ADK) e é destinada principalmente a administradores de sistema e profissionais de TI. A versão da ferramenta relevante lançada pela Microsoft em setembro de 2026 oferece suporte ao Windows 11 26H2.
O Windows Latest informou que o autor encontrou o EmulateHeap em seu computador com Windows 11 26H2. As etapas específicas são as seguintes:
Primeiro, baixe o Windows ADK do site oficial da Microsoft e inicie o programa de instalação. Na interface de seleção de funções, basta selecionar Ferramentas de compatibilidade de aplicativos, que é a ferramenta de compatibilidade de aplicativos, e concluir a instalação.
Após a conclusão da instalação, procure Administrador de Compatibilidade no menu Iniciar e abra a versão de 32 bits. Como um grande número de programas antigos da era do Windows 95 usa arquitetura de 32 bits, a versão de 32 bits é uma ferramenta que vale a pena usar primeiro ao verificar esses mecanismos de compatibilidade.
Depois de abrir o programa, clique com o botão direito em Novo banco de dados na área Bancos de dados personalizados, selecione Criar novo e entre no Modo de compatibilidade. Em seguida, procure EmulateHeap na lista de correções de compatibilidade disponíveis para ver esse recurso.
É importante observar que encontrar uma correção de compatibilidade na lista não significa que ela fará com que todos os programas mais antigos sejam executados corretamente.
A Microsoft já encontrou problemas semelhantes antes. Após a atualização do Windows 11 22H2, alguns usuários relataram que o jogo “Grand Theft Auto: Vice City” apresentou problemas de perda de som e “Need for Speed: Most Wanted” travou após ativar certas correções de compatibilidade.
Isso significa que a própria correção de compatibilidade também pode causar conflitos com outros componentes do sistema ou código do jogo. Mesmo que um determinado mecanismo possa resolver um tipo de problema histórico, isso não significa que seja adequado para todos os programas.
Portanto, não há necessidade de usuários comuns ativarem o EmulateHeap apenas para tentar executar um jogo antigo. Se você encontrar um problema com software mais antigo que não está em execução, é mais prudente procurar recomendações de compatibilidade específicas para esse programa antes de decidir se deseja aplicar a correção.
Por que o Windows simplesmente não limpa esse código antigo?
Do Windows 95 ao Windows 11, a Microsoft fez muitas alterações no sistema operacional. Quer se trate de gerenciamento de memória, sistemas gráficos, mecanismos de segurança ou ambiente de execução de drivers e aplicativos, o Windows moderno é muito diferente dos sistemas da década de 1990.
Mas o sistema operacional não é um produto que possa ser desmontado e reconstruído a qualquer momento, independentemente do software antigo.
Ao longo de décadas de desenvolvimento, milhões de aplicativos confiaram nas interfaces e nos comportamentos fornecidos pelo Windows. Alguns desses programas são desenvolvidos estritamente de acordo com a documentação oficial, enquanto outros, inconscientemente, dependem do comportamento de certas versões do sistema.
Enquanto esses programas ainda forem usados, a Microsoft precisará considerar o possível impacto da modificação dos mecanismos subjacentes.
Para software comum, problemas de compatibilidade após atualizações do sistema operacional podem causar apenas alguns inconvenientes. Mas para software empresarial, ferramentas profissionais e programas legados que ainda executam tarefas comerciais reais, as quebras de compatibilidade podem causar danos ainda maiores.
Como resultado, a Microsoft mantém há muito tempo uma grande estrutura de compatibilidade de aplicativos. Sua função não é apenas informar ao programa antigo em qual versão do Windows ele está sendo executado, mas também interceptar algumas chamadas do sistema, ajustar comportamentos específicos ou habilitar correções de compatibilidade especializadas com base no programa específico.
Essas medidas geralmente são transparentes para os usuários. Quando um programa antigo é iniciado, o sistema aplica as correções correspondentes em segundo plano e os usuários podem não estar cientes de que o sistema operacional alterou algum comportamento do programa.
EmulateHeap é um exemplo desse sistema.
Sua existência não significa que a Microsoft pense que o Windows 95 tem melhor gerenciamento de memória do que os sistemas modernos, mas significa que alguns programas mais antigos dependiam de comportamentos anteriores. Para evitar quebrar esses programas, a Microsoft optou por manter um conjunto de implementações legadas na estrutura de compatibilidade, em vez de forçar todos os softwares a serem reescritos de acordo com as regras dos sistemas modernos.
Essa abordagem tem vantagens e custos. Pode prolongar a vida útil de software antigo e reduzir os obstáculos para os usuários atualizarem o sistema, mas também aumentará a complexidade de manutenção do sistema operacional, fazendo com que algum código histórico exista por muito tempo em sistemas modernos.
Nem todos os softwares clássicos recebem tratamento igual
A disposição da Microsoft em manter códigos especiais de compatibilidade para alguns programas antigos não significa que todos os softwares clássicos possam continuar a ser executados no Windows moderno.
Um exemplo típico é o 3D Pinball, que já foi integrado ao Windows, e é um jogo de pinball tridimensional. Um dos motivos pelos quais o jogo não estava mais disponível na versão de 64 bits do Windows era que ele apresentava problemas de compatibilidade de 64 bits que exigiam trabalho adicional, e a Microsoft não dedicou recursos para corrigi-los completamente.
Isso contrasta com a situação do EmulateHeap.
Para alguns softwares que são amplamente utilizados, têm valor comercial importante ou podem continuar a ser executados com modificações relativamente limitadas, a Microsoft pode estar disposta a investir recursos na manutenção da compatibilidade. Para outros programas, a Microsoft poderá optar por não fornecer mais suporte se o custo do reparo for muito alto ou se a demanda do usuário tiver diminuído significativamente.
Portanto, a compatibilidade do Windows não é um compromisso ilimitado. Requer compensações constantes entre custos de manutenção, necessidades do usuário, riscos de segurança e complexidade técnica.
Vale a pena notar que a Microsoft continuou a modernizar a interface do Windows nos últimos anos. Por exemplo, a empresa está substituindo gradualmente algumas das caixas de diálogo de propriedades que sobraram da era do Windows 95 por novas interfaces baseadas no WinUI 3.
Mas a modernização da interface e a manutenção da compatibilidade subjacente podem ser realizadas ao mesmo tempo. A janela vista pelo usuário pode ter adotado uma nova tecnologia de design, mas algum código antigo ainda é retido dentro do sistema para garantir que os aplicativos históricos não perderão compatibilidade devido a atualizações na interface ou na arquitetura do sistema.
Esta é também uma das diferenças importantes entre o Windows e muitas plataformas de software relativamente jovens: o Windows não só precisa de suportar aplicações modernas, mas também de acomodar tanto quanto possível o enorme ecossistema de software que se formou ao longo de décadas.
A tradição de compatibilidade que continua do Windows 95 ao Windows 11
A história do EmulateHeap pode parecer apenas uma anedota técnica sobre jogos antigos e gerenciadores de memória, mas na verdade reflete uma estratégia central de longa data do Windows.
Quando "SimCity" teve problemas na versão beta do Windows 95, a Microsoft optou por modificar o sistema operacional para tolerar o bug no jogo. Desde então, à medida que mais programas antigos foram expostos à dependência do comportamento histórico do sistema, a Microsoft estabeleceu gradualmente um mecanismo de reparo de compatibilidade mais completo.
Hoje, o Windows 11 ainda mantém código que pode simular o comportamento de gerenciamento de memória do Windows 95, e os usuários podem encontrá-lo por meio das ferramentas de gerenciamento fornecidas pela Microsoft.
Isso não significa que o Windows moderno ainda dependa da arquitetura central do Windows 95, nem significa que os computadores comuns estejam executando um sistema operacional antigo em segundo plano. O que realmente foi transferido foram alguns dos códigos de compatibilidade e as ideias de design da Microsoft para evitar ao máximo a quebra de software antigo.
Para um sistema operacional com décadas de existência, essa abordagem representa um fardo técnico e uma vantagem competitiva. Quando os usuários atualizam para uma nova versão do Windows, muitas vezes desejam continuar usando o software que adquiriram, as ferramentas com as quais estão familiarizados e os fluxos de trabalho que acumularam ao longo dos anos. Ao manter alguns códigos antigos, a Microsoft reduziu os riscos de compatibilidade causados pela atualização do sistema operacional.
Desta perspectiva, o gerenciador de memória do Windows 95 oculto no Windows 11 não é uma simples relíquia histórica, mas uma manifestação concreta do compromisso de longo prazo da Microsoft com a compatibilidade de software. Mesmo que as interfaces dos sistemas operacionais continuem a mudar e as plataformas de hardware continuem a ser atualizadas, alguns códigos de décadas atrás podem continuar a funcionar simplesmente porque permitem que um jogo ou programa antigo continue a ser executado nos computadores atuais.
Comentários