Segredos do WindowsO Windows pode mas não vai

Raymond Chen

O Windows realmente pode substituir uma DLL em uso, renomeando a original e copiando o novo arquivo no lugar certo. Entretanto, o mundo do Windows prefere não fazer isso. Por quê?

Mesmo que você substitua um arquivo que está em uso, ainda pode haver código no sistema que deseja usar a versão antiga. Por exemplo, suponhamos que dois arquivos, A.DLL e B.DLL, trabalhem juntos. Você publica uma correção que atualiza os dois, mas A.DLL está em uso. Não tem problema. Os dois, simplesmente, são substituídos. Como resultado, os programas que ainda estiverem usando A.DLL continuarão usando a antiga versão, mas os novos programas usarão a nova. E todos os programas obtêm a nova versão de B.DLL.

Agora, um programa que estava usando a antiga versão de A.DLL decide chamar uma função. Naturalmente, ele espera a antiga versão de B.DLL, mas em vez disso obtém a nova. Dependendo do tipo de alteração feita em B.DLL, essa chamada pode funcionar ou falhar. As duas DLLs supõem que sua parceira vem do mesmo conjunto correspondente.

Mesmo que você esteja atualizando apenas uma única DLL sem nenhuma dependência, ainda poderão haver alguns problemas já que a DLL precisa interoperar com versões anteriores de si própria.

Suponhamos que você substitua ole32.dll enquanto está ele em uso. Um programa recém-iniciado chama o novo ole32.dll e inicia uma operação de arrastar e soltar. O usuário arrasta o objeto em uma janela criada por um dos programas que foram iniciados antes da atualização. Agora o novo ole32.dll envia mensagens para o antigo ole32.dll.

Ao escrever o código para fazer a comunicação entre os processos, em geral, espera-se que a mesma versão do código seja executada em cada processo, porque os dois pontos de extremidade no canal de comunicação precisam entrar em acordo sobre o que irão comunicar! "Enviarei a mensagem 5, que significa 'solicito texto', e espero que você responda me enviando a mensagem 12, que significa 'aqui está o texto solicitado'." Se os dois lados não estiverem executando a mesma versão do código, há o risco de que o mecanismo de comunicação seja diferente; a diferença pode ser sutil, mas realmente é capaz de causar uma incompatibilidade.

Digamos que você adicionou um campo a uma estrutura e, por acaso, essa estrutura é usada como parte da mensagem 5. Ótimo. Agora você tem duas versões incompatíveis da mensagem 5: uma usa a estrutura antiga e a outra, a nova. Se os dois lados da comunicação não entrarem em um acordo sobre a estrutura, a mensagem 5 não funcionará.

Se tiver de oferecer suporte à execução das versões antiga e nova lado a lado, será necessário inventar uma nova mensagem, digamos, mensagem 52, e fazer a nova versão da DLL oferecer suporte à mensagem 5 e 52. É preciso saber qual versão da DLL está sendo executada no outro lado primeiro para enviar a mensagem apropriada.

Mesmo que não tenha alterado a estrutura em si, você pode ter alterado o significado de alguns de seus campos. Se a estrutura tiver uma enumeração e a nova versão adicionar um novo valor à ela, ainda assim haverá incompatibilidade entre a antiga e a nova.

Obviamente, você pode tentar definir novas mensagens sempre que publicar uma correção e escrever código para oferecer suporte à interoperabilidade entre a versão antiga e a nova durante o intervalo em que as duas versões conflitantes da DLL forem executadas simultaneamente. No entanto, a situação poderá complicar quando você estiver na sua terceira correção e tiver quatro conjuntos diferentes de mensagens: um para a versão original os outros para cada uma das correções.

Mesmo que você exija que as correções sejam instaladas em seqüência, isso não ajudará muito; enquanto permitir que o programa original seja executado, você terá de continuar a interoperar com ele.

E depois as pessoas escreverão artigos denegrindo a sua imagem porque você demora muito para publicar correções!

O problema não é que o Windows tenha de reiniciar depois de substituir um arquivo em uso, mas apenas que seria melhor não ter de lidar com a complexidade dos resultados se isso não acontecer. A engenharia é uma série de compensações. Você se daria ao trabalho de oferecer suporte a antigas versões suas em um caso em que não é nem mesmo uma configuração de estado estável recomendada?

O site de Raymond Chen, The Old New Thing (A velha novidade), e seu livro homônimo tratam da história do Windows e da programação Win32. Ele espera que você faça um retorno seguro às origens.