Segredos do WindowsComo lidar com problemas de compatibilidade

Raymond Chen

HAVIA UM PROGRAMA escrito para o Windows® 3.1 que abria o painel de controle de impressoras procurando a janela Painel de Controle, acessando o menu Arquivo e pesquisando um item chamado Impressora. No Windows 95, o Painel de controle não tinha uma opção Impressora em Arquivo. Como resultado, quando executado em um Windows 95, esse programa postava uma mensagem de comando incorreto no Painel de controle. Para resolver esse problema, o Windows 95 criou uma janela falsa do Painel de controle para ser encontrada pelo programa. Quando o programa postava a mensagem no painel falso, a pasta Impressoras era aberta.

Algumas pessoas argumentam que o Windows 3.1 deveria detectar que o programa estava fazendo hipóteses falsas sobre o Painel de controle e exibir um aviso. Dessa forma, o autor do programa teria visto o aviso e corrigido o problema antes do lançamento do produto. Mas para detectar a intenção de uma parte do código, é preciso um grau de análise que entra no domínio da inteligência artificial. Essencialmente, o Windows 3.1 teria que detectar que um programa estava fazendo um strcmp para Impressoras, analisar strcmp em particular e resolver se era ruim. Mas isso só resolve o caso de Impressoras. Quantas verificações de compatibilidade você quer que o sistema execute? E quanto aos falsos positivos?

Outro argumento é que o Windows 95 deveria responder a essa hipótese ruim com uma caixa de diálogo de aviso que tivesse escrito "O programa XYZ está fazendo algo ruim". Mas para que o Painel de controle soubesse o que postou a mensagem de erro, a detecção teria que ser colocada no gerenciador de janelas. Isso cria uma conexão frágil entre dois componentes - o Painel de controle e o gerenciador de janelas. Novamente, isso aborda apenas um caso. Você quer que o gerenciador de janelas seja fragilmente conectado a todos os outros componentes do sistema?

Seria mais fácil fornecer uma mensagem genérica, sem nomear o aplicativo específico. Mas essa também não é uma boa solução. Uma mensagem de erro vaga não é melhor do que nenhuma mensagem de erro. Além disso, essa caixa de diálogo seria, na melhor das hipóteses, ignorada pelo usuário, particularmente porque ela não recomendaria nenhuma medida a ser adotada. Os usuários perceberiam a caixa de diálogo como um aborrecimento. Esse é um ponto muito importante. É essencial que toda mensagem de erro permita uma ação. Se o usuário souber como reagir ao aviso, a caixa de diálogo torna-se útil.

Outro problema é que uma caixa de diálogo cria um ponto de reentrância devido ao loop da caixa de diálogo. Esse é um problema técnico. A reentrância inesperada é uma das principais fontes de bugs na programação da interface do usuário. Da mesma forma, o Painel de Controle em si pode estar em um estado modal e a exibição de uma caixa de diálogo faz com que a estrutura modal desmorone.

Uma caixa de diálogo também cria uma nova carga de localização. Se uma caixa de diálogo for escrita para cada problema de compatibilidade, haverá centenas delas espalhadas por todo o sistema. Cada uma teria que ser traduzida em 33 idiomas para os quais o Windows oferece traduções completas.

Finalmente, pense na reação dos concorrentes quando seus produtos resultarem em uma dessas caixas de diálogo. Eles diriam coisas do tipo "a Microsoft está culpando outras pessoas por seu próprio sistema operacional cheio de bugs" e "a Microsoft está intencionalmente fazendo nosso programa parecer ruim". Eu não estou exagerando. Já houve empresas que reclamaram no Congresso de que a Microsoft estava visando e desativando seus softwares de forma mal-intencionada. Após uma inspeção detalhada, foi descoberto que havia bugs em seus programas. Honestamente, é melhor simplesmente corrigir os bugs para eles do que enfrentar uma demorada investigação do Congresso.

Como resultado, as versões atuais do Windows exibem uma caixa de diálogo de aviso apenas quando um programa é tão incompatível com o Windows que não pode ser executado de forma alguma ou só pode ser executado com sérias limitações. Mesmo nesse caso, a Microsoft tenta trabalhar com o fornecedor para garantir que nenhum cliente fique desapontado. Afinal de contas, as pessoas querem executar os programas nos sistemas operacionais que compraram. Quando um programa não funciona, você não quer saber de quem é a culpa - tudo o que você quer é trabalhar.

Raymond Chen, A velha coisa nova, trata da história do Windows e da programação Win32. Ele está trabalhando em um livro, que por coincidência também se chama The Old New Thing (Addison-Wesley, 2007).

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..