Windows confidencial: Uma viagem ao passado com o EmulateHeap
Raymond Chen
Um dos extremamente simples — ainda completamente doido — compatibilidade comportamentos disponíveis em Application Compatibility Toolkit é chamado EmulateHeap.
Se você ativar a correção de compatibilidade em um processo e, em seguida, a pilha de nível de sistema operacional funciona (de HeapCreate para LocalLock para GlobalReAlloc e a qualquer momento entre) são redirecionados para funções de substituição que emulam a pilha de Windows 95 até o último detalhe.
Por exemplo, você pode ter um programa que aloca dois blocos de memória, libera as duas, aloca um terceiro bloco de memória e depende do fato de que o ponteiro retornado pela alocação de terceira é numericamente idêntico ao ponteiro retornado pela primeira alocação, porque esse é o que acontece no Windows 95.
Você pode ter um programa que estoura um buffer de pilha e sofre sem conseqüências sérias porque a memória que vem após o buffer de pilha não está sendo usada para qualquer coisa ou pelo menos o que é o que acontece no Windows 95.
Você pode também estar executando um programa que libera a memória e, em seguida, acessa à memória liberada algum tempo depois, esperando que a memória ainda conterá os valores que estava quando ela foi liberada e ainda não foi reutilizada para alguns outra alocação de memória ou pelo menos não for reutilizada no Windows 95. (Ou até mesmo scarier, que o programa depende do fato de que os valores forem alterados após a memória foi liberada de uma maneira muito específica!)
Há um monte de pequenos pouco estranhas dependências como este em aplicativos mais antigos. Esses aplicativos não foram codificados que forma intencionalmente; esses comportamentos foram erros pouco espalhados aqui e ali, erros de programas gerenciados para escapar porque eles aconteceram para não causar problemas quando executados em conjunto com o Gerenciador de heap do Windows 95. E, em seguida, quando esses programas são executados em qualquer outra versão do Windows, eles falhar porque as outras versões do Windows tem um Gerenciador de heap diferentes.
Agora, isso não faz o Gerenciador de heap do Windows 95 “ melhor ” ou “ mais robusta ” que as outras. É apenas diferente. Há provavelmente só como muitos comportamentos que consiga sobreviver sem falhas no Windows 7 poderia ter paralisado no Windows 95. O efeito que você esteja vendo é self-selection apenas: Se você escreveu um programa em 1995 tinha um bug que travou no Windows 95, você clicaria Observe e corrigi-lo como Windows 95 era sua plataforma de destino!
Quando a correção de compatibilidade EmulateHeap está ativada em um processo, o comportamento do Gerenciador de heap é alterado para que ele alinha todas as estrelas para exatamente as posições em 1995. Todos os coincidences que ocorreram no Windows 95 — esses coincidences aplicativos foram inadvertidamente confiar em — mais uma vez são forçados a ocorrer, para que os aplicativos que contêm esses tipos de erros seriam continue em execução exatamente da mesma maneira que era antes. Lembre-se você forçar todos os coincidences à linha de backup também significa que novos recursos de heap, como Low fragmentação devem ser desativados, porque esses recursos seriam deslocar coincidences que foram depender de aplicativos.
Isso explica a parte simples.
O motivo pelo qual este também é doido: A forma como a pessoal de gerenciado para emular o Gerenciador de heap do Windows 95 então perfeitamente a compatibilidade do aplicativo é que eles simplesmente levaram uma cópia do código-fonte do Gerenciador de heap do Windows 95, recompilado-lo e adicionado à infra-estrutura de compatibilidade. Em outras palavras, há uma cópia de uma parte significativa do kernel do Windows 95 dentro a estrutura de compatibilidade de aplicativos do Windows. Não é bem toda uma copiar do Microsoft Bob, mas nesse caso, a parte do código levantada intacta do Windows 95 é mais do que ballast; se a correção de compatibilidade EmulateHeap estiver habilitada em um processo que o código antigo obtém carregado da unidade de disco rígido e começa a fazer o trabalho real!
Windows 7 tem um novo subsistema de heap tolerante a falhas tenta detectar muitas classes de erros de memória de heap do aplicativo simples e aplicar atenuações automaticamente. Por exemplo, libera duplo de falha temporária tolerante a detecta e corrige, saturações de buffer de pilha (saturações de pelo menos pequenas) e o uso de memória depois de liberá-la (pelo menos se você usá-lo apenas um breve período após liberá-la). Felizmente, essa solução mais geral significa que a próxima versão do Windows não necessário incluir uma cópia do Gerenciador de heap do Windows 7 dentro de seus arquivos de infra-estrutura de compatibilidade.
Raymond Chen * Site da Web, The Old New Thing e escreveu um livro (Addison-Wesley, 2007), homônimo lidam com Windows histórico, programação Win32 e destruir seus fones de ouvido Zune acidentalmente.*