Os arquivos da área de trabalhoWhen I’m x64

Wes Miller

Há mais de cinco anos, o Windows XP tem sido disponibilizado no modo nativo para arquiteturas de 64 bits. Entretanto, a menos que você tenha sido um dos pioneiros no uso do processador Intel Itanium (o Windows XP para Itanium lançado no mesmo dia que o Windows XP), você já deve ter ouvido falar, mais recentemente, da disponibilidade dessa arquitetura no Windows XP e nas versões do Windows

Server 2003 para sistemas x64. O x64 – também chamado no setor de x86-64 – é o nome genérico para as arquiteturas AMD64 (AMD) e EM64T (Intel). Além disso, se você tiver adquirido um novo computador no ano passado ou não muito antes disso, há uma boa chance de que ele esteja equipado com a arquitetura de 64 bits, mesmo se estiver em um ambiente de 32 bits (o que é mais provável).

Atualmente, trabalho em uma pequena empresa de desenvolvimento em Austin, Texas. Devido à arquitetura de um de nossos produtos, estamos interessados em aproveitar alguns benefícios muito específicos da arquitetura x64 – muito semelhante à equipe do Microsoft® Exchange 2007, que se estabeleceu e começou a fornecer exclusivamente a arquitetura x64. Da mesma forma, a equipe de desenvolvimento e teste que gerencio executa implantações exclusivamente em versões x64 do Windows® XP e do Windows Server® 2003 para estações de trabalho de desenvolvimento, laptops, servidores e servidores de produção. Além disso, executo o Windows XP Professional x64 Edition no meu laptop pessoal para testar e depurar o nosso produto.

Curiosamente, a primeira resposta que recebo da maioria das pessoas quando menciono execução da versão de 64 bits do Windows – especialmente em um sistema móvel – é um olhar de estranheza. E quando estão familiarizadas com a computação de 64 bits, a reação é de descrença, relutância e espanto – devido à premissa comumente assumida de que é difícil agrupar drivers de dispositivo em sistemas de 64 bits. Na coluna deste mês, explicarei como e por que utilizo o Windows XP e o Windows Server 2003 em sistemas x64 no modo de 64 bits; além disso, descreverei alguns dos benefícios (e obstáculos) da implantação que você poderá ter. Também apresentarei alguns aspectos do suporte, da migração e da implantação do Windows Vista™ x64.

Um breve histórico

Como mencionado anteriormente, a origem do suporte a 64 bits no Windows realmente iniciou com o suporte ao processador Intel Itanium. (Embora o Windows estivesse disponível para o processador Alpha de 64 bits, o Windows nunca foi, de fato, de 64 bits quando executado no Alpha.) Não é oferecido suporte para o Itanium no Windows XP e no Windows Vista, de forma que a arquitetura de x64 atualmente é conduzida pela computação cliente do Windows de 64 bits. Uma ampla seleção de edições do Windows Server 2003 está atualmente disponível para x64, além do Itanium (o qual foi, essencialmente, relegado às cargas de trabalho de datacenter de ultra high-end) – uma tendência que espero que continue no lançamento da próxima versão do Windows Server, cujo codinome é “Longhorn”.

O suporte para o Windows na plataforma x64 foi disponibilizado no lançamento do Windows Server 2003 Service Pack 1 (SP1). Embora isso possa parecer um pouco confuso, também aconteceu quando a versão x64 do Windows XP foi disponibilizada – o que significa que os produtos de 32 bits e 64 bits do Windows XP são derivados de diferentes árvores de códigos no Windows. Embora os produtos de 32 bits atualmente tenham um segundo service pack disponível, a versão de 64 bits do Windows XP tecnicamente não possui qualquer nível de service pack (ou seja, você poderia considerá-la como tendo o SP1 para Windows Server 2003 já integrado).

Para executar a versão de 64 bits do Windows – o Windows XP, o Windows Server 2003, o Windows Vista ou o Windows Server “Longhorn” – os requisitos são, na verdade, os mesmos. Obviamente, primeiro você precisa ter um processador com capacidade para 64 bits. No caso da AMD, isso significa obter um sistema de um, dois ou quatro núcleos que aproveite a compatibilidade AMD64 (consulte http://www.amd.com/br-pt/Processors/ProductInformation/0,,30_118,00.html). Para a Intel, isso significa obter um sistema de um, dois ou quatro núcleos que aproveite o suporte EM64T ou a Arquitetura Intel 64 (acesse intel.com/technology/intel64). Observe que os detalhes são a parte maçante. Um sistema Intel Core Duo, por exemplo, não tem capacidade para 64 bits. Um sistema Intel Core 2 Duo tem capacidade para 64 bits – mesmo se for chamado de simplesmente Centrino Duo (como no caso do meu laptop).

Trabalhando com x64

Assim que tiver definido se o seu sistema oferecerá suporte no modo nativo a uma versão de 64 bits do Windows, você precisará lidar com o suporte do dispositivo. Infelizmente, por mais que a Microsoft tenha incentivado fornecedores e OEMs (por meio de, pelo menos, dois anos de sessões de WinHEC) para que criassem e certificassem drivers de 64 bits para seus dispositivos e sistemas, o maior desafio que você enfrentará ao usar o Windows x64 será encontrar drivers para dispositivos de hardware ou para software. Com base na minha experiência, você terá mais êxito se executar o x64 em um servidor, no qual o suporte necessário ao dispositivo é limitado; além disso, o benefício do x64 é mais lógico.

É muito difícil encontrar drivers para sistemas móveis e de desktop. Em geral, você terá mais sorte com um renomado provedor OEM ou com um sistema baseado em componentes de classe empresarial (em que a probabilidade de uso comercial fará com que o fornecedor ou OEM crie e ofereça drivers com capacidade x64).

Para o Windows Vista, felizmente essa situação é muito melhor. Em vez de um ambiente em que x86 é a arquitetura preferida e x64 é a arquitetura ignorada, devido à disponibilidade limitada de drivers para a maioria de hardware, ocorre o oposto. Para o Windows Vista, um fornecedor de dispositivos deve submeter os drivers x64 a testes de compatibilidade. Na verdade, os drivers x86 não precisam ser incluídos, mas certamente podem ser, se for o caso. Conceitualmente, isso significa que determinado hardware – especialmente os dispositivos que aproveitam os recursos do novo Windows Vista – pode, na verdade, ter suporte somente para o x64 Windows, e não para x86.

A realidade é que os drivers são apenas um dos problemas que você enfrentará ao tentar executar a versão de 64 bits do Windows no modo nativo. O problema maior é chegar lá (ou migrar) para iniciar, mas abordaremos isso posteriormente.

Por que 64 bits?

É claro que a AMD, a Intel e a Microsoft não migraram para a arquitetura de 64 bits somente por diversão. A migração para 64 bits oferece vários benefícios importantes. Como você pode observar na Figura 1, o aprimoramento mais importante oferecido pela arquitetura x64 é atender significativamente a uma maior capacidade de memória – até 16 terabytes (TB) versus 4 GB, que é a capacidade atendida pela versão de 32 bits do Windows. Observe que apesar de os indicadores de 63 bits atenderem a esse limite de 16 TB, eles têm acesso a apenas aproximadamente 8 TB.

Figure 1 Limites de espaço de endereço na memória

Espaço de endereço Windows 64 bits Windows 32 bits
Memória virtual 16 TB 4 GB
Arquivo de paginação 512 TB 16 TB
Reserva de memória paginável 128 GB 470 MB
Reserva de memória não paginável 128 GB 256 MB
Cache do sistema 1 TB 1 GB

Além disso, as versões x64 do Windows fornecem prevenção de execução de dados (DEP) baseada em hardware – também disponível nos sistemas x86 com suporte NX (No Execute, não executar). Isso permite que uma solução acionada por hardware utilizada pelo Windows impeça estouros de buffer. Ela impede a execução de código a partir das páginas de dados na memória – consulte support.microsoft.com/kb/875352 para obter mais informações sobre esse tópico.

As versões x64 do Windows permitem o suporte nativo de CPUs com vários processadores ou núcleos, exatamente como as versões do Windows o fazem. Porém, uma das maiores complexidades da geração de imagens de um sistema Windows XP é eliminada pelo uso de uma única camada de abstração do hardware (HAL) em todas as instalações do Windows x64 – é o fim da dificuldade para identificar a HAL em uso em sistemas sem ACPI ou com uma única CPU.

Basicamente, como uma arquitetura, o Windows x64 permite que você use a sua infra-estrutura de gerenciamento e o software de 32 bits existentes (por meio de emulação), além do software de 64 bits com a capacidade de acesso a essa memória significativamente aprimorada. Na verdade, os únicos efeitos colaterais desagradáveis de migrar para o Windows x64 são: a total falta de suporte para aplicativos de 16 bits (inclusive “pegadinhas” como aplicativos de 32 bits com instaladores de 16 bits); problemas com aplicativos que não são executados de modo confiável quando a DEP baseada em hardware estiver habilitada (embora a DEP possa ser desabilitada por processo, e a equipe de Compatibilidade de aplicativos Windows corrija alguns aplicativos que não são executados corretamente com a DEP habilitada); e, finalmente, o fato de que na versão de 64 bits do Windows Vista, todos os drivers devem ser assinados digitalmente.

Esse último item foi acrescentado para ajudar a impedir violação com o kernel do Windows na memória, uma técnica freqüentemente utilizada por rootkits. A expectativa é que, como a x64 é a arquitetura para a qual a Microsoft está incentivando os fornecedores a desenvolverem drivers como prioridade (a fim de obter drivers por meio dos testes de qualidade de hardware do Windows), isso não é tão assustador para uma exigência, como poderia ser historicamente.

Há alguns outros pontos a serem observados ao se considerar o Windows para sistemas x64. Não há versões do Windows XP para sistemas x64 que tenham a funcionalidade incluída no Windows Media® Center Edition ou no Windows Tablet PC Edition. No entanto, isso será alterado no Windows Vista, no qual as versões x64 do Windows têm a mesma funcionalidade que as versões x86.

Virtualização

Um item que não mencionei é a virtualização. Não estou me referindo aos produtos de virtualização Microsoft Virtual PC ou VMWare PC; estou falando sobre a virtualização de sistema operacional para executáveis de 32 bits. Nas versões de 32 bits do Windows, os aplicativos de 16 bits são todos executados no contexto de NTVDM – uma máquina virtual MS-DOS®. Como mencionado anteriormente, não é oferecido suporte para aplicativos de 16 bits nas versões de 64 bits do Windows. Em vez disso, embora a maioria dos componentes integrados do Windows sejam executados no modo nativo como binários de 64 bits, alguns componentes e vários programas de terceiros são executados como aplicativos de 32 bits.

O Windows oferece uma camada de emulação totalmente nova, denominada Windows On Windows (WOW), a qual permite que esses aplicativos de 32 bits tenham uma exibição diferente do sistema operacional – na verdade, serão executados em uma versão de 32 bits do Windows. Na WOW, os aplicativos x86 exibem os Arquivos de Programas (X86) simplesmente como Arquivos de Programas. Do mesmo modo, o %WINDIR%\SysWOW64 aparece para aplicativos x86 como %WINDIR%\System32. Os aplicativos x86 exibem a chave do Registro HKLM\SOFTWARE\Wow6432Node como eles a exibiriam no próprio nó HKLM\SOFTWARE.

Ao usar a ferramenta Process Explorer, você pode espreitar outra perspectiva da virtualização. Como é esperado que muitos aplicativos de 32 bits interajam com binários integrados de 32 bits do Windows, vários desses binários são fornecidos em versões de 64 e 32 bits. Ao adicionar uma coluna extra ao Process Explorer, você pode facilmente visualizar isso. Na Figura 2, você observará duas instâncias de cmd.exe – uma versão de 32 bits e outra de 64 bits. Observe que na instância selecionada de 32 bits, você verá várias DLLs wow64* carregadas no processo de 32 bits. Essas DLLs mostram a execução da virtualização, a qual permite que aplicativos de 32 bits funcionem na versão de 64 bits do Windows. Além disso, observe que o diretório de trabalho (Caminho) está sendo utilizado pelas versões de 64 e 32 bits do cmd.exe.

Figura 2 O Process Explorer revela as versões de 32 e 64 bits do cmd.exe

Figura 2** O Process Explorer revela as versões de 32 e 64 bits do cmd.exe **(Clique na imagem para aumentar a exibição)

Uma última observação sobre o tópico de virtualização – apesar de o Windows executar o explorer.exe como um aplicativo nativo de 64 bits, isso apresenta alguns prós e contras. O maior contra é que qualquer extensão do shell do Explorer deve ser recompilada para x64 para que funcione (a maioria não tem isso).

O oposto ocorre no Internet Explorer® – como padrão, ele é executado no modo nativo com a versão de 32 bits. Isso é feito principalmente para que a abundância de controles ActiveX® na Internet já em uso atualmente funcionem com êxito da forma como estão. Sem isso, como os aplicativos de 64 bits não podem carregar as DLLs de 32 bits ou drivers em processo, não há uma forma eficaz de carregar os controles ActiveX de 32 bits, o que compromete praticamente todos os controles ActiveX disponíveis no momento em um navegador de 32 bits – isso significa que uma parte considerável do conteúdo de Internet ficaria inacessível. Para visualizar isso na prática, tente carregar C:\Program Files\Internet Explorer\iexplore.exe em um sistema de 64 bits do Windows e acessar qualquer site que carregue conteúdo de controle ActiveX (até mesmo o Windows Update) – o resultado será variados graus de falha. O Windows Update (consulte a Figura 3) agora foi atualizado para abrir uma instância de 32 bits do Internet Explorer nessa situação. No futuro, certamente haverá algum conteúdo de controle ActiveX atualizado para aproveitar a versão de 64 bits do Internet Explorer. No entanto, como no momento a maioria dos sistemas Windows são executados puramente na versão de 32 bits do Windows, a necessidade de que o conteúdo de controle ActiveX seja atualizado não é fundamental. Essa mudança deverá demorar ainda um longo período para ser implementada.

Figura 3 Os controles de 32 bits do ActiveX falham na versão de 64 bits do Internet Explorer

Figura 3** Os controles de 32 bits do ActiveX falham na versão de 64 bits do Internet Explorer **(Clique na imagem para aumentar a exibição)

x64 Windows na Pluck

Mencionei no início deste artigo que iniciamos a transição para o x64 Windows na Pluck. Efetuamos isso com três diferentes versões do Windows: Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64 e Windows Vista x64.

A nossa empresa é pequena o suficiente, de forma que quando começamos a desenvolver o nosso produto mais recente, foi possível iniciar a migração para o Windows para x64, a fim de aproveitar os seus benefícios. Fazer isso significava garantir que todo o novo hardware solicitado tivesse capacidade para x64. Na verdade, são os recursos de memória expandida do x64, em combinação com a virtualização, que nos permitem executar o nosso produto da forma como fizemos. Todos os nossos servidores físicos são executados como servidores virtuais de 64 bits em um servidor host de 64 bits. Cada servidor host possui 16 GB de RAM, divididos entre os servidores virtuais hospedados nele (geralmente 2 GB para cada máquina virtual de teste ou VM, e 3 GB para cada VM de produção).

Ao usar sistemas de camada 1 e hardware virtualizado, conseguimos atingir praticamente 100% de suporte para o dispositivo. O meu laptop, por exemplo, possui três dispositivos que não têm drivers x64 disponíveis. Todos esses parecem ser dispositivos do tipo backplane, os quais não são fundamentais, e o sistema é executado normalmente sem a sua presença. O mais interessante é que uma instalação do Windows Vista RC1 x64 resultou exatamente no suporte para o mesmo dispositivo, embora o meu sistema tenha o logotipo Windows Vista Capable; certamente esses drivers faltando serão fornecidos em breve pelo fornecedor.

Como o nosso uso dos sistemas é basicamente restrito ao Microsoft Office, Visual Studio® e várias ferramentas adicionais utilizadas em nosso processo de desenvolvimento e criação, nós temos muitos aplicativos herdados que causaram problemas de compatibilidade na nossa migração. Apesar de uma considerável parte da nossa empresa utilizar versões de 32 bits do Windows, iniciamos a migração para 64 bits com o novo hardware e foi tudo relativamente tranqüilo.

Implantação e migração de x64

Há algumas considerações que se fazem necessárias em relação à implantação. A Microsoft fornece uma versão do Windows Pre-installation Environment (Windows PE) especificamente para a arquitetura x64. No entanto, como há paridade x86 nos sistemas x64, talvez você queira usar o Windows PE x86 na implantação – especialmente se estiver usando uma solução de geração de imagens. Se você estiver implantando o Windows XP usando uma instalação autônoma, o Windows PE precisará ser específico para a arquitetura – já que o winnt32.exe precisa ser executado na mesma arquitetura de implantação. Como o Windows PE não apresenta uma camada de compatibilidade para 32 bits, e o winnt32.exe em x64 é um aplicativo de 64 bits, a versão de 32 bits do Windows requer o Windows PE de 32 bits. O mesmo se aplica para as versões de 64 bits do Windows, as quais requerem o Windows PE de 64 bits.

Os Serviços de Instalação Remota (RIS) são diferentes nesse aspecto; por isso, utilizamos o RIS na Pluck. O RIS, começando com o Windows Server 2003 SP1, pode implantar as arquiteturas x64 e o x86 ou Itanium do Windows. Quando um sistema x64 se conectar a um servidor RIS, o servidor (na configuração padrão) oferecerá imagens RISetup x86 e x64 ou RIPrep. O RIS pode ser configurado para oferecer também aos clientes x64 imagens exclusivamente de x86 ou x64. A opção foi oferecida como padrão, a fim de fornecer a melhor experiência com o hardware x64.

Observe que eu não mencionei ainda a atualização. Há um bom motivo para isso. Infelizmente, a atualização de todo um sistema operacional de x86 para x64 é uma tarefa maciça. Por esse motivo – e devido à implantação limitada do Windows XP Pro x64 Edition – não é possível atualizar para o Windows XP x64 de qualquer versão x86, nem de qualquer versão do Windows XP (x86 ou x64) para o Windows Vista x64. O Windows Vista nos sistemas x64 é, como o Windows XP Pro x64 Edition anterior a ele, um produto somente para instalação limpa. Por esse motivo, muitas empresas consideram a migração para x64 somente quando uma atualização de hardware estiver envolvida – uma estratégia semelhante que várias empresas podem precisar realizar com o próprio Windows Vista (tornando a execução de duas tarefas ao mesmo tempo potencialmente uma execução lógica).

Mas isso não significa que os usuários ou empresas migrando do x86 Windows para o x64 Windows não tenham ferramentas prontamente disponíveis – eles certamente as possuem. As versões da Ferramenta de migração de perfil do usuário (USMT) para o Windows XP e para o Windows Vista foram ampliadas para oferecer suporte à migração (versus uma atualização em banda do sistema operacional) de uma instalação do Windows para outra. Atualmente, esse é o método predominante na maioria das empresas que implantam o Windows independentemente – limpeza e recarregamento, inclusive no mesmo computador –, de forma que o fato de utilizarem o mesmo mecanismo para migrar para o Windows em uma arquitetura totalmente nova não será um obstáculo tão difícil como antes.

Conclusão

Embora a migração gradual de nossa pequena empresa para o x64 possa ser consideravelmente mais fácil do que o amplo processo de migração enfrentado por grandes empresas, cada profissional de TI deve começar a considerar uma possível migração para a arquitetura x64. A realidade é que, embora a arquitetura x86 e as versões nativas x86 do Windows ainda estarão presentes na próxima década, a arquitetura x64 certamente será o futuro da computação empresarial. Com a Microsoft migrando totalmente para recursos x64 com o Exchange Server e outros produtos, você deve começar a analisar onde os sistemas x64 se encaixarão primeiramente na sua arquitetura, bem como onde eles serão adequados para o seu plano de migração para o Windows Vista, independentemente de você estar utilizando, no momento, o Windows XP ou o Windows Server 2003 no modo nativo nos seus sistemas x64.

Wes Miller é gerente de desenvolvimento da Pluck (www.pluck.com) em Austin, no Texas. Antes disso, trabalhou na Winternals Software e na Microsoft, como gerente de programas e gerente de produtos do Windows. Ele pode ser contatado pelo email technet@getwired.com.

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