Skip to main content

Noções básicas sobre a compatibilidade de aplicativos

Há vários motivos pelos quais um aplicativo que funcionava em versões anteriores do Windows possa falhar no Windows 8 até que você tome uma medida para corrigi-lo. Quantos desses aplicativos que não funcionam você vai encontrar dependerá, em grande parte, da versão do Windows que você está usando hoje. A transição do Windows XP para o Windows Vista foi, sem dúvida, o obstáculo mais desafiador da história recente. Em comparação, o Windows 7 apresentou alta compatibilidade com o Windows Vista, e o Windows 8 está revelando ser altamente compatível com o Windows 7. De modo que se você estiver usando o Windows Vista ou superior, há chances de que você tenha sorte e uma experiência muito mais fácil migrando seus aplicativos para o Windows 8! Se você ainda estiver usando o Windows XP (ou até mesmo uma versão anterior do Windows), provavelmente terá um pouco mais de trabalho pela frente. Mas, como inúmeros clientes têm demonstrado, esse é um desafio superável que pode ser vencido quando você adota a abordagem certa de compatibilidade de aplicativos.

Por que os aplicativos falham quando você migra para um sistema operacional mais atualizado? Às vezes, é porque um aplicativo tinha uma dependência de comportamento não documentado do sistema operacional, seja porque o desenvolvedor intencionalmente usou uma API não documentada ou porque o desenvolvedor acidentalmente confiou em um comportamento que se revelou ser uma coincidência, e não uma promessa. (Com o Microsoft Developer Network, ou MSDN, a documentação massiva como é hoje, é comprovadamente bastante difícil entender completamente todos os comportamentos possíveis do sistema operacional!) Às vezes, os recursos e comportamentos são desativados, muitas vezes devido a questões de segurança, mas também como resultado da falta de adoção do mercado ou da substituição por uma tecnologia superior. De forma frustrante, a causa mais frequente da falha na compatibilidade de aplicativos é uma verificação da versão. Isto é, o aplicativo está verificando a versão do sistema operacional e, em seguida, escolhendo falhar intencionalmente se descobrir qualquer versão diferente daquelas nas quais escolhe ser executado. Basicamente, o aplicativo está se recusando a deixar que você tente executá-lo no novo sistema operacional, mesmo que ele, de alguma forma, funcione perfeitamente!

Se você estiver interessado em detalhes específicos, fornecemos o Guia de Compatibilidade do Windows 8 e Windows Server 2012 para ajudar a explicar as alterações na compatibilidade. No entanto, o público-alvo do Guia é o desenvolvedor que está escrevendo o código. Este artigo, pelo contrário, usa a perspectiva dos profissionais de TI que estão tentando migrar suas organizações para o Windows 8. Aqui, discutimos a motivação por trás das alterações feitas no Windows 8, bem como o possível impacto dessas alterações.

Neste artigo:


Aumentando a confiabilidade

Uma vez que a Microsoft continua melhorando a segurança geral e a confiabilidade do sistema operacional, entendemos que nenhum desses investimentos poderia ser totalmente percebido enquanto a maioria dos usuários estivesse em execução como administradores locais. Obviamente, esse foi o caso para motivos históricos. O MS-DOS, e versões anteriores do Microsoft Windows, não tinham conceito de computadores compartilhados e verificações de segurança. Embora o Windows NT tenha introduzido uma infraestrutura de segurança robusta, ele também demonstrou compatibilidade com aplicativos existentes do MS-DOS e Windows que nunca foram desenvolvidos para um sistema operacional seguro com vários usuários. Muitos clientes dependiam desses aplicativos e como resultado deixavam os respectivos usuários como administradores locais. No entanto, usuários administradores apresentam gerenciamento significativamente mais caro que usuários padrão, e os clientes do mundo todo estavam clamando por um meio de tornar uma porcentagem maior de seus usuários em usuários padrão. Obviamente, alguns foram bem-sucedidos, mas foi quase sempre um processo caro e doloroso, e alguns buracos tiverem que ser abertos na configuração de segurança do sistema operacional para oferecer suporte a aplicativos que dependiam dos privilégios do administrador.

No Windows Vista, introduzimos o recurso UAC (Controle de Conta de Usuário) para finalmente quebrar o ciclo de administradores locais direcionando aplicativos que dependiam dos direitos do administrador local e, portanto, exigiam mais administradores locais. Por fim, os clientes puderam perceber uma redução significativa no TCO (custo total de operações), juntamente com a postura de segurança superior de um ambiente de usuário padrão. Esse recurso, acima de tudo, era um recurso de compatibilidade. Ele fornecia soluções automatizadas a vários desafios de compatibilidade, como gravações de arquivo e registro em locais protegidos ou falha de aplicativos de instalação que dependem de permissões do administrador para instalação em locais globais. Ele também fornecia mais opções de correção que podiam ser aplicadas manualmente a aplicativos para resolver problemas extras de compatibilidade que surgiam com aplicativos em execução sob permissões do usuário padrão.

Além de corrigir aplicativos de terceiros, o UAC também melhorou a experiência de usuários padrão de várias maneiras. Por exemplo, adicionamos um recurso em que os usuários padrão podem alterar o fuso horário quando viajam (uma reivindicação muito comum desses clientes que foram bem-sucedidos na implantação de usuários padrão no Windows XP ou anterior). Também introduzimos uma nova infraestrutura de segurança, com base na confiança do aplicativo além da identidade do usuário, que nos permitiu implementar o comportamento de área restrita. Softwares, como o Internet Explorer e os aplicativos do Microsoft Office 2010, aproveitaram essas áreas restritas para aprimorar a defesa abrangente da segurança. O Windows 8 estende essa infraestrutura de segurança baseada na confiança ainda mais com contêineres de aplicativo.

Observe que, como o UAC fornece a infraestrutura de segurança para contêineres de aplicativo, se você desabilitar esse recurso, não será possível executar os aplicativos da Windows Store. Por esse motivo, os clientes que optaram por desabilitar o UAC no Windows Vista ou Windows 7 agora devem pensar seriamente em habilitá-lo no Windows 8 e resolver os problemas de compatibilidade com usuários padrão que muito provavelmente fizeram com que o UAC fosse originalmente desabilitado.

O UAC fornece benefícios tangíveis até mesmo para administradores locais. Ao executar administradores locais com credenciais de segurança que são bastante parecidos com usuários padrão na maior parte do tempo, os usuários que mais frequentemente têm uma necessidade legítima de manter direitos de administrador local (desenvolvedores e administradores de TI) podem ter um ambiente no qual os softwares e os scripts que criam não criem dependências acidentais adicionais dos direitos do administrador local. Essa alteração já teve um impacto significativo sobre os ISVs (fornecedores independentes de software), que agora estão criando softwares que quase sempre são executados perfeitamente bem com os direitos de usuário padrão graças ao UAC. Ela tem o mesmo impacto dentro da empresa.

No Windows Vista e posterior, também adicionamos um recurso chamado WRP (Proteção de Recursos do Windows), que utiliza outra extensão para a infraestrutura de segurança do Windows: a capacidade de proteger recursos para acesso somente por um serviço específico, e não pela identidade da conta sob a qual o serviço está em execução. Isso torna particularmente difícil para um aplicativo (quase sempre um instalador que incluiu cada dependência de DLL quando ela foi criada) gravar acidentalmente uma cópia de uma versão muito antiga de um sistema DLL do Windows NT 4.0 (p. ex., shell32.dll) sobre a cópia usada pelo Windows 8, que, como você pode imaginar, tem um resultado razoavelmente catastrófico! Em vez disso, somente o serviço que lida com o Windows Update (o serviço Instalador de Módulos do Windows) é capaz de modificar esses arquivos por padrão. E, é claro, também fornecemos opções de correção para esses aplicativos, de modo que a falha ao gravar nesses arquivos não causa falha irreparável de seus aplicativos!

Voltar ao início


Aprimorando a segurança

Quase por definição, aprimorar a segurança envolve prevenir que coisas aconteçam e impedir que pessoas mal-intencionadas façam essas coisas. No entanto, é possível que aplicativos dependam de recursos para fazer algumas dessas coisas - especialmente aplicativos mais antigos que possam ter sido desenvolvidos antes de ser comumente sabido como as pessoas mal-intencionadas podiam explorar um recurso para fazer o mal. Em alguns casos, adicionamos um recurso para bloquear um comportamento que nunca existiu antes. Em outros casos, modificamos os padrões para bloquear o comportamento por padrão quando permitíamos previamente o comportamento por padrão e exigíamos que você optasse por desbloqueá-lo.

O modo protegido do Internet Explorer, por exemplo, fornece uma área restrita de segurança que restringe consideravelmente a capacidade dos controles ActiveX hospedados em uma página de acessar o sistema operacional. A partir do Internet Explorer 8, o modo protegido é habilitado por padrão nas zonas Internet e Sites Restritos. Muitos clientes que têm uma dependência dos controles ActiveX descobrem que seus tamanhos internos não são zoneados corretamente para a zona Intranet Local (que desabilita o modo protegido por padrão) e, portanto, acham esses aplicativos menos compatíveis.

A Microsoft introduziu o suporte ao sistema operacional para DEP (Prevenção de Execução de Dados) com o Windows XP SP2. O DEP é um recurso de proteção de memória, com suporte do software e do hardware, que reduz significativamente a capacidade do malware de atacar o sistema usando técnicas como os estouros de buffer. Ele ajuda a proteger contra código mal-intencionado que é injetado por meio de pontos de entrada de dados de um aplicativo. No entanto, o Windows 8 ainda deixa o DEP configurado para ser aceito, com a finalidade de maximizar a compatibilidade. Os novos aplicativos da Windows Store aceitarão o DEP, mas os aplicativos existentes da área de trabalho terão as restrições do DEP aplicadas somente se aceitarem esse recurso. O Internet Explorer teve o recurso de aceitação do DEP a partir da versão 7 e habilitado por padrão a partir da versão 8. Isso significa que os controles ActiveX que geram e executam código dinamicamente, mas que falham ao marcar a respectiva memória como executável, terão uma exceção gerada (que, se não tratada pelo aplicativo, causará falha do aplicativo) toda vez que tentarem executar esse código.

Para clientes que ainda estão migrando do Windows XP ou versões anteriores, o Isolamento da Sessão 0 ainda pode apresentar um desafio na transferência para o Windows 8. A execução de um serviço do Windows é historicamente na Sessão 0, e continua assim até hoje. No Windows XP e versões anteriores, o primeiro usuário a fazer logon no computador também era executado na Sessão 0. Quando os recursos do computador eram muito mais limitados, essa era uma abordagem mais eficiente. No entanto, apesar de ser parcimoniosa com os recursos, essa abordagem expunha uma parte considerável da área da superfície de segurança, já que os aplicativos geralmente executados com privilégios do Sistema Local coabitavam com outros aplicativos em execução com muito menos privilégios, fornecendo uma oportunidade tentadora de elevação de privilégio. Consequentemente, não fazemos mais logon dos usuários na Sessão 0; essa sessão é apenas para serviços. Os aplicativos de serviço que devem se comunicar com o usuário ou seus programas diretamente muitas vezes precisam encontrar novos mecanismos para essa comunicação.

Continuamos adicionando recursos de segurança ao Internet Explorer, uma vez que ele faz parte do sistema operacional que mais frequentemente se conecta com agentes potencialmente mal-intencionados. Por exemplo, o recurso Proteção contra Rastreamento no Internet Explorer 9 e Internet Explorer 10 ajuda os usuários a proteger a respectiva privacidade bloqueando agentes de rastreamento enumerados. No entanto, muitos dos mesmos sites que estão rastreando o comportamento online também estão fornecendo funcionalidade de aplicativo Web. Assim, muitos scripts podem falhar ao serem carregados e executados quando residem em um domínio bloqueado por uma das suas Listas de Proteção contra Rastreamento.

De forma semelhante, o recurso Filtro SmartScreen no Internet Explorer ajuda a proteger você contra downloads mal-intencionados. No Internet Explorer 8, o Filtro SmartScreen protege você de uma lista de downloads mal-intencionados conhecidos. No Internet Explorer 9, o Filtro SmartScreen foi aprimorado para adicionar reputação, o que exige que os downloads criem uma reputação antes de serem marcados como positivos e, de alguma forma, gerem um aviso de que o download é novo e, portanto, ainda não reconhecido como positivo. O Windows 8 traz esse conceito para o sistema operacional, ajudando a proteger você contra downloads que ainda não estabeleceram uma reputação positiva, independentemente do navegador usado para obtê-los. No entanto, isso pode causar falhas em alguns cenários em que você baixa arquivos executáveis que mudam frequentemente, mas que não são assinados, ou em que você tenha apenas downloads ocasionais de quantidade insuficiente para ter desenvolvido uma reputação de aplicativo até o momento.

Voltar ao início


Melhorando o desempenho e os recursos

Uma das mudanças frequentemente citadas pelos clientes corporativos para migrar para a versão mais recente do Windows é a capacidade de aproveitar os recursos e o desempenho de um sistema operacional de 64 bits. Embora a versão de 64 bits forneça a capacidade de executar aplicativos que precisam acessar grandes quantidades de memória e de aproveitar uma grande quantidade de RAM, há um impacto potencial de compatibilidade. Embora o Windows de 64 bits possa executar seus aplicativos existentes de 32 bits, ele não pode executar aplicativos existentes de 16 bits. Ele também não oferece suporte aos drivers de dispositivo existentes de 32 bits. Se você tiver um dispositivo que não tenha um driver de dispositivo de 64 bits ou aplicativos de 16 bits críticos à missão, então será preciso executá-los em um sistema operacional de 32 bits.

Outro possível impacto na empresa ao executar o Windows de 64 bits é o impacto em aplicativos .NET que interoperam com código nativo, seja por meio da Interoperabilidade COM ou Interoperabilidade P/Invoke. A configuração de compilador padrão para aplicativos .NET é chamada de "Qualquer CPU", o que significa que esses aplicativos se tornarão aplicativos de 64 bits em um sistema operacional de 64 bits, mas se tornarão aplicativos de 32 bits em um sistema operacional de 32 bits. Se eles forem chamados em código nativo, este precisará ser do mesmo tipo (64 ou 32 bits) do aplicativo de chamada. Desse modo, quando o aplicativo for chamado em código nativo e esse código for compilado como um código de 32 bits, essa chamada falhará ao carregar essa DLL. Felizmente, esse é um problema relativamente fácil de corrigir, seja alterando a configuração do compilador ou modificando o executável diretamente usando o utilitário CorFlags, mas que vale ser mencionado em razão da frequência com a qual achamos que isso afeta aplicativos do cliente corporativo.

O Windows Vista introduziu um novo modo de exibição, chamado DWM (Gerenciador de Janelas da Área de Trabalho). O DWM mudou o modelo histórico, no qual aplicativos renderizavam diretamente na memória na tela e, em vez disso, fez com que aplicativos renderizassem em bitmaps fora da tela, o que seria então composto pelo DWM para criar a exibição que os usuários veem. Com essa abordagem, os benefícios são significativos para o desempenho e a experiência de usuário. No entanto, vários tipos de aplicativos eram incompatíveis com o DWM. Para as empresas, o maior impacto foi em aplicativos remotos, que muitas vezes usam drivers de espelhamento para redirecionar a exibição. A partir do Windows 8, não é mais possível desabilitar o DWM, pois agora ele é básico e central para a experiência do sistema operacional. Embora tenhamos feito o possível para manter a maioria dos aplicativos funcionando, os aplicativos que continuam usando abordagens históricas nem sempre podem funcionar.

Um aspecto importante do desempenho para usuários móveis é a vida da bateria. Com o novo modelo para aplicativos da Windows Store no Windows 8, os aplicativos não são apenas de tela inteira e imersivos, eles também são suspensos quando não estão visíveis. Consequentemente, eles não consumirão ciclos de CPU e, portanto, não estarão descarregando a bateria. No entanto, historicamente, os aplicativos existentes sempre estiveram em execução, consumindo CPU e bateria, desde a hora que são iniciados até a hora que são encerrados. Para ajudar a bateria a ter a maior duração esperada pelos usuários, mesmo com aplicativos existentes da área de trabalho, o Windows 8 executa etapas para diminuir aplicativos de serviço existentes (bloqueando a quantidade de CPU que tenham permissão para usar) e para suspender aplicativos interativos quando eles não estiverem em uso e a tela for desligada. Embora isso corresponda às expectativas do usuário (ao apertar o botão de energia no dispositivo móvel, você espera que o aplicativo não continue em execução a pleno vapor), isso também pode causar um problema para aplicativos que não estão esperando ser suspensos. Felizmente, esse impacto é relativamente mínimo.

Voltar ao início


Elevando a usabilidade

Uma vez que as exibições do computador contêm mais e mais pixels em telas cada vez menores, é importante alterar a exibição para tornar tudo maior enquanto ele ainda estiver em execução com os recursos de exibição completos e não interpolados. O Windows tem oferecido suporte à funcionalidade de DPI Alto em várias versões, suporte que continuará sendo melhorado em cada versão subsequente. A partir do Windows 7, o suporte para DPI Alto era robusto o suficiente para começar a detectar e padronizar configurações de DPI mais apropriadas com base na exibição. No entanto, ainda sobram alguns aplicativos para os quais as configurações de DPI alto são um problema e, se uma parte significativa dos dispositivos que você pretende implantar se beneficiar de uma configuração de DPI alto, testar seus aplicativos nesse cenário é um investimento que vale a pena.

Voltar ao início


Removendo componentes herdados

Embora façamos o melhor para manter a compatibilidade com aplicativos herdados, há alguns casos em que oferecer suporte a um determinado recurso não é mais possível, seja porque ele bloqueia nossa capacidade de fornecer uma substituição superior ou porque o recurso apresenta falhas que nos impedem de atingir nossas metas de desempenho, confiabilidade ou segurança. Nesse caso, substituímos o recurso. Embora não seja uma lista completa, há algumas substituições que causaram alguns problemas de compatibilidade na empresa e vale a pena serem mencionadas aqui.

No Windows Vista, removemos o suporte para drivers de impressora no modo kernel. Isso devido a motivos de confiabilidade. Uma falha em um driver no modo kernel leva a uma falha de tela azul do sistema inteiro, enquanto uma falha em um driver no modo de usuário leva somente a uma falha de driver. De modo geral, estamos movendo o máximo possível de funcionalidade para fora do modo kernel, especialmente quando a confiabilidade é um problema, sem comprometer nossa capacidade de fornecer objetivos de desempenho. Embora a maioria dos clientes não tenha mais impressoras que forneçam apenas drivers no modo kernel, nós os encontramos de vez em quando, especialmente em impressoras avançadas e plotadoras que, devido ao preço, têm uma expectativa de vida acima da média. Frequentemente, nos deparamos com desafios relacionados a impressoras virtuais, como as que geram arquivos PDF; versões antigas dessas impressoras muitas vezes aproveitam drivers de modo kernel que não são mais executados.

Também temos retirado gradativamente arquivos WinHelp como um formato de arquivo de ajuda. Esse formato de arquivo foi introduzido em 1990 no Windows 3.0. Fornecemos seu sucessor, a Ajuda HTML, em 1997 com o Internet Explorer 4.0. Embora o suporte aos arquivos WinHelp continue ativo, no Windows Vista, a preocupação com a área de superfície de segurança adicional nos levou a remover o WinHelp do sistema operacional adequado. O conteúdo do arquivo de ajuda era tão eficiente nesse formato que equivalia a um arquivo executável. No entanto, dado o volume massivo de conteúdo do WinHelp gerado há mais de duas décadas de suporte, continuamos fornecendo suporte baixável para o Windows Vista e o Windows 7, com a intenção de forneceremos o mesmo para o Windows 8.

Os meios pelos quais você faz logon no Windows há muito têm sido extensíveis, mas o mecanismo que usávamos historicamente permitia apenas que um provedor trabalhasse por vez. Esse mecanismo também exigia que os provedores desenvolvessem todo o código e criassem toda a experiência de usuário para o processo de logon. A partir do Windows Vista, substituímos esse modelo pelo modelo Provedor de Credenciais, que exige apenas que os desenvolvedores implementem a parte da autenticação que seja diferente daquela já fornecida e que também proporcionem a capacidade de que vários provedores trabalhem em uníssono. No entanto, essa mudança de arquitetura exige que qualquer aplicativo que fornecia um modo alternativo de fazer logon no Windows XP ou em versões anteriores seja reescrito.

Voltar ao início


Resumo

Neste artigo, exploramos alguns dos investimentos que fizemos no Windows que possam ter um impacto negativo na compatibilidade de seus aplicativos existentes. A compatibilidade há muito tempo tem sido um dogma no desenvolvimento do Windows, de modo que sempre levamos a compatibilidade com versões antigas de maneira bastante séria. Esperamos que este artigo explique algumas das motivações por trás dessas mudanças e possa ajudar você a entender as trocas que nós e você temos que fazer.

Embora a transição do Windows XP ou de versões anteriores para o Windows 8 possa, muitas vezes, demonstrar uma taxa de falha de 20% ou mais alta (se hoje você estiver usando especificamente softwares antigos e executando áreas de trabalho do administrador local), há várias opções de correção disponíveis para solucionar rapidamente a grande maioria dessas falhas e liberar sua equipe para se concentrar nos aplicativos que exigem intervenções mais significativas. Dessa forma, a taxa de falhas na transição do Windows Vista ou posterior para o Windows 8 está de longe comprovando estar na porcentagem de um único dígito bem baixo (e a culpa disso são as inoportunas verificações de versão embutidas em código!). Desse modo, você deve estar apto a estender e maximizar seus investimentos em ativos de software por mais tempo ainda com o Windows 8. Boa sorte com seus esforços para compatibilidade de aplicativos!

Voltar ao início

Principais tarefas

Sobre o autor

Foto de Chris JacksonChris Jackson, também conhecido como " O cara da compatibilidade de aplicativos", é um consultor principal e líder técnico da equipe SWAT da Experiência com Aplicativos do Windows. Um especialista mundialmente reconhecido no campo da compatibilidade de aplicativos do Windows, Chris criou documentações técnicas, treinamentos e ofertas de serviços usados dentro e fora da Microsoft, com base nos anos de experiências reais com clientes corporativos e fornecedores independentes de software.

Chris é o autor ou coautor de vários documentos e artigos técnicos que discorrem sobre a compatibilidade de aplicativos, além de ser um colaborador da TechNet Magazine. Ele também é um palestrante de destaque em grandes conferências do setor no mundo todo, incluindo TechEd, IT Forum e Microsoft Management Summit.

Recursos relacionados

Mantenha-se informado

A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site.

Deseja participar?