Archivos del escritorioCuando mi sistema es x64

Wes Miller

Durante más de cinco años, Windows XP ha estado disponible de forma nativa para arquitecturas de 64 bits. Pero, a menos que usted fuera uno de los primeros usuarios del procesador Intel Itanium (Windows XP para Itanium se lanzó al mercado el mismo día que Windows XP), es posible que haya oído hablar más de él recientemente con la disponibilidad de las versiones de Windows XP y Windows.

Server 2003 para sistemas x64. El término x64 (también se usa en el sector x86-64) es el nombre genérico para la arquitectura AMD64 de AMD y EM64T de Intel. Si adquirió un PC nuevo en el último año más o menos, es muy posible que sea compatible con 64 bits, aunque funcione a 32 bits (como la mayoría de los ordenadores).

Actualmente, trabajo en una joven empresa en Austin, Tejas. Debido a la arquitectura de uno de nuestros productos, estamos interesados en aprovechar algunas ventajas específicas de la arquitectura x64 (en gran parte como el equipo de Microsoft ® Exchange 2007, que ha abierto un nuevo camino y ha empezado lanzar al mercado productos únicamente para la arquitectura x64). De forma similar, el equipo de desarrollo y pruebas que dirijo se encarga únicamente de versiones x64 de Windows ® XP y Windows Server ® 2003 para estaciones de trabajo de desarrollo, equipos portátiles, servidores y servidores de producción. Además, uso Windows XP Professional x64 Edition en mi equipo portátil con el fin de probar y depurar nuestro producto.

Curiosamente, la primera respuesta que obtengo de la mayoría de las personas cuando menciono que uso Windows de 64 bits (en especial, en un sistema portátil) es una mirada bastante confusa. Y si están familiarizadas con la informática de 64 bits, la reacción se sitúa entre la incredulidad, la nausea y el asombro, debido a la creencia comúnmente establecida de que resulta complicado reunir controladores de dispositivo para los sistemas de 64 bits. En la columna de este mes, explicaré cómo y por qué uso Windows XP y Windows Server 2003 en sistemas x64 en el modo de 64 bits, asimismo describiré algunas de las ventajas (y obstáculos) que encontrará en su implementación. También describo aspectos de la compatibilidad, migración e implementación de Windows Vista™ x64.

Breve historia

Como he indicado anteriormente, el origen de la compatibilidad con 64 bits en Windows comienza con la compatibilidad para el procesador Intel Itanium. (Aunque Windows estaba disponible para el procesador Alfa de 64 bits, realmente, nunca fue de 64 bits cuando se ejecutaba en este procesador). En Windows XP y Windows Vista, no hay compatibilidad para Itanium, de modo que la arquitectura x64 actualmente es la portadora de la antorcha de la informática de cliente de Windows de 64 bits. En estos momentos, la selección de ediciones de Windows Server 2003 disponibles para x64 es mayor que para Itanium (que se ha relegado fundamentalmente a cargas de trabajo de centros de datos de tecnología muy avanzada), una tendencia que espero mantener con la versión siguiente de Windows Server, denominada "Longhorn", cuando se lance al mercado.

La compatibilidad para Windows en la plataforma x64 empezó a estar disponible cuando se lanzó al mercado Windows Server 2003 Server Pack 1 (SP1). Aunque puede resultar confuso, en esos momentos la versión x64 de Windows XP también empezó a estar disponible (lo que significa que los productos de 32 bits y de 64 bits de Windows XP se derivaban de diferentes árboles de códigos dentro de Windows). Mientras que, actualmente, los productos de 32 bits tienen un segundo service pack disponible, la versión de 64 bits de Windows XP técnicamente no tiene un nivel de service pack (o se podría interpretar que tiene un SP1 para Windows Server 2003 integrado).

Los requisitos para ejecutar Windows de 64 bits (Windows XP, Windows Server, Windows Vista o Windows Server "Longhorn") son idénticos. Obviamente, en primer lugar, debe tener un procesador con compatibilidad para 64 bits. En el caso de AMD, esto significa contar con un sistema de uno, dos o cuatro núcleos que ofrezca compatibilidad para AMD64 (consulte amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). Para Intel, se debe buscar un sistema de uno, dos o cuatro núcleos que ofrezca compatibilidad para EM64T, o bien, Intel 64 Architecture (consulte intel.com/technology/intel64). Tenga en cuenta los detalles de más abajo. Un sistema Intel Core Duo, por ejemplo, no está preparado para 64 bits. Un sistema Intel Core 2 Duo es compatible con 64 bits (aunque se le podría denominar simplemente Centrino Duo, como ocurre con mi equipo portátil).

La vida con x64

Una vez haya determinado si su sistema es compatible con una versión de 64 bits de Windows de forma nativa, deberá solucionar el tema de la compatibilidad de dispositivos. Lamentablemente, a pesar de que Microsoft ha animado a proveedores y OEM (a través de sesiones de WinHEC durante al menos dos años) a crear y certificar controladores de 64 bits para sus dispositivos y sistemas, el desafío más grande al que se enfrenta cuando usa Windows x64 es encontrar controladores para dispositivos de hardware o software. Según mi experiencia, la opción que ofrece los mejores resultados es ejecutar x64 en un servidor donde la compatibilidad de los dispositivos necesaria esté limitada y donde las prestaciones de x64 sean las más evidentes.

Resulta más difícil encontrar controladores para el escritorio y para los sistemas móviles. Por lo general, tendrá más posibilidades con un proveedor OEM de primera línea o con un sistema fabricado con componentes de clase empresarial (donde la probabilidad de un uso empresarial empuja al proveedor u OEM a crear y firmar controladores compatibles con x64).

Para Windows Vista, afortunadamente, está situación experimenta una gran mejora. En vez de un mundo donde la arquitectura preferida es x86 y x64 la relegada con muy pocos controladores disponibles para la mayoría del hardware, ocurre totalmente lo contrario. Para Windows Vista, un proveedor de dispositivos debe realizar pruebas de compatibilidad con los controladores x64. De hecho, no es necesario incluir también los controladores x86, aunque podría hacerse. Conceptualmente, esto significa que algún hardware (especialmente los dispositivos que se benefician de las capacidades nuevas de Windows Vista) podría ser únicamente compatible con Windows x64 y no con x86.

La realidad es que los controladores son solamente un problema con el que tropezará cuando intente ejecutar Windows de 64 bits de forma nativa. El gran problema, en primera instancia, reside en llegar hasta allí (o en migrar); pero me detendré en este aspecto más adelante.

¿Por qué 64 bits?

AMD, Intel y Microsoft no se han pasado a la arquitectura de 64 bits únicamente por diversión, evidentemente. Al hacerlo se obtienen varias ventajas clave. Como puede comprobar en la Figura 1, la mejora más importante que ofrece la arquitectura de x64 es la capacidad de administrar apreciablemente más memoria (hasta 16 terabytes (TB) frente a las 4 GB que administra Windows de 32 bits). Tenga en cuenta que, mientras que los punteros de 64 bits pueden administrar hasta ese máximo de 16 TB, las aplicaciones tienen acceso únicamente a aproximadamente 8 TB.

Figure 1 Límites del espacio de direcciones de memoria

Por otra parte, las versiones de x64 de Windows están preparadas para la prevención de ejecución de datos (DEP), que también se encuentra disponible en sistemas x86 con compatibilidad con NX (No Execute). Con esto es posible tener una solución controlada por hardware, la cual Windows usa para evitar desbordamientos de búfer. Evita la ejecución de código desde páginas de datos en la memoria (consulte support.microsoft.com/kb/875352 para obtener más información sobre este tema).

Las versiones x64 de Windows tienen compatibilidad nativa con CPU de multiprocesador o multinúcleo, tal como ocurre con las versiones x86 de Windows. Pero una de las mayores complejidades de la creación de imágenes de un sistema Windows XP queda eliminada gracias al uso de un único nivel de abstracción de hardware (HAL) en todas instalaciones de Windows x64 (se acabaron los problemas para identificar la HAL que se está usando en sistemas que no son ACPI o en de una CPU única).

Básicamente, Windows x64 como arquitectura le permite usar la infraestructura de administración y el software de 32 bits existentes (a través de la emulación), además del software de 64 bits con la capacidad de tener acceso a la memoria considerablemente mejorada. De hecho, los únicos efectos secundarios desfavorables al pasar a Windows x64 son: la ausencia completa del compatibilidad con aplicaciones de 16 bits (incluyendo trampas como aplicaciones de 32 bits con instaladores de 16 bits); los problemas con las aplicaciones que no se ejecutan de forma confiable cuando la DEP en hardware se habilita (aunque la DEP se puede deshabilitar proceso a proceso y el equipo de Compatibilidad de aplicaciones con Windows pule algunas aplicaciones que no se ejecutan correctamente cuando la DEP está habilitada); y, finalmente, el hecho de que en Windows Vista de 64 bits todos los controladores deben tener firma digital.

Se decidió agregar este último aspecto para ayudar a evitar alteraciones con el kernel de Windows en la memoria, una técnica frecuentemente usada por los rootkits. Lo que se prevé, ya que Microsoft está fomentando entre los proveedores el desarrollo de controladores para la arquitectura x64 (con el fin de que los controladores se someta a pruebas de calidad para el hardware de Windows), es que este requisito no resulte tan temido como antiguamente.

Hay un par de otros puntos a tener en cuenta cuando se considera el uso de Windows para sistemas x64. No existen versiones de Windows XP para sistemas x64 que contengan la funcionalidad incluida en Windows Media ® Center Edition o en Windows Tablet PC Edition. Sin embargo, en Windows Vista es diferente, ya que las versiones x64 de Windows tienen la misma funcionalidad que las versiones x86.

Virtualización

No he mencionado aún la virtualización. No me refiero a Microsoft Virtual PC ni a los productos de virtualización de VMWare PC; me estoy refiriendo a la virtualización del sistema operativo para archivos ejecutables de 32 bits. En las versiones de 32 bits de Windows, las aplicaciones de 16 bits se ejecutan todas en el contexto de NTVDM (Virtual MS-DOS® Machine). Como apunté anteriormente, no hay compatibilidad para aplicaciones de 16 bits en las versiones de 64 bits de Windows. En su lugar, mientras que la mayoría de los componentes integrados de Windows se ejecutan de forma nativa como binarios de 64 bits, algunos componentes y muchos programas de terceros se ejecutan como aplicaciones de 32 bits.

Windows le ofrece un nivel de emulación totalmente nueva denominada Windows On Windows (WOW) con el fin de que estas aplicaciones de 32 bits puedan obtener una vista diferente del sistema operativo (ejecutándose eficazmente en una versión de 32 bits de Windows). Con WOW, las aplicaciones x86 ven Archivos de programa (X86) simplemente como Archivos de programa. Igualmente, %WIN­DIR%\SysWOW64 aparece en las aplicaciones x86 como %WINDIR%\System32. Las aplicaciones x86 ven la clave del registro HKLM\SOFT­WARE\Wow6432Node como verían el nodo HKLM\SOFT­WARE.

Al usar la herramienta Explorador de procesos, puede explorar otra perspectiva de virtualización. Debido a que se espera que muchas aplicaciones de 32 bits interactúen con binarios de Windows de 32 bits integrados, muchos de estos binarios se encuentran disponibles en las versiones de 64 y 32 bits. Lo podrá comprobar fácilmente si agrega una columna adicional al Explorador de procesos. En la Figura 2, advertirá dos instancias de cmd.exe: una versión de 32 bits y una versión de 64 bits. Podrá comprobar que en la instancia de 32 bits que está resaltada hay varios DLL wow64* cargados en el proceso de 32 bits. Estos muestran el proceso de la virtualización, que permite que aplicaciones de 32 bits puedan funcionar en Windows de 64 bits. Tenga en cuenta también el directorio de trabajo (ruta) que usan las versiones de 64 y 32 bits del cmd.exe.

Figura 2** El Explorador de procesos muestra las versiones de 32 y de 64 bits de cmd.exe **(Hacer clic en la imagen para ampliarla)

Finalmente, una cosa más que se debe tener en cuenta en la virtualización: que Windows ejecute explorer.exe como una aplicación de 64 bits nativa, tiene sus pros y sus contras. La mayor desventaja es que la extensión del shell de Explorer se debe recompilar para x64 al objeto de que pueda funcionar (la mayoría no lo está).

En Internet Explorer® ocurre lo contrario: se ejecuta nativamente con la versión de 32 bits de forma predeterminada. Principalmente, esto es así para que la gran cantidad de controles ActiveX ® que se usan actualmente en Internet puedan funcionar correctamente tal cual. Si no fuera así, y debido a que las aplicaciones de 64 bits no pueden cargar DLL ni controladores en procesos de 32 bits, no existe un método eficaz para cargar controles ActiveX de 32 bits que comprendan la mayoría de los controles ActiveX actualmente disponibles, en un explorador de 64 bits, lo que implicaría que bastante contenido de Internet sería inaccesible. Para comprobar esto en la práctica, intente cargar C:\Archivos de Programa\Internet Explorer\iexplore.exe en un sistema de Windows de 64 bits y visitar cualquier sitio que cargue contenidos del control ActiveX (incluso Windows Update), como resultado obtendrá errores de distintos grados. Windows Update (véase la Figura 3) ha actualizado la forma de abrir una instancia de 32 bits de Internet Explorer en esta situación. En el futuro, habrá seguramente ciertos contenidos de control ActiveX actualizados que se podrán beneficiar de Internet Explorer de 64 bits. No obstante, debido a que hoy en día la mayoría de los sistemas de Windows ejecutan exclusivamente Windows de 32 bits, no es fundamental que los contenidos de ActiveX estén actualizados. No creo que esto cambien durante bastante tiempo.

Figura 3** Los controles ActiveX de 32 bits producen errores en Internet Explorer de 64 bits **(Hacer clic en la imagen para ampliarla)

Windows x64 en Pluck

Al principio de este artículo, mencioné que en Pluck hemos iniciado la transición a Windows x64. Lo henos hecho en tres versiones diferentes de Windows: Windows XP Profesional x64 Edition, Windows Server 2003 Enterprise Edition x64 y Windows Vista x64.

Nuestra empresa es lo suficientemente pequeña de modo que, cuando comenzamos a desarrollar nuestro producto más reciente, pudimos empezar a migrar hacia Windows x64 con el fin de beneficiarnos de sus ventajas. Al hacerlo de esta forma, todo el hardware que pedimos era compatible con x64. De hecho, las capacidades de memoria ampliada de x64 junto con la virtualización nos permitió ejecutar nuestro producto de la forma que deseábamos. Todos los servidores físicos se ejecutaban como servidores virtuales de 64 bits en un servidor host de 64 bits. Cada servidor host tiene 16 GB de RAM dividida entre los servidores virtuales hospedados en ella (por lo general, 2 GB para cada equipo virtual de almacenamiento provisional o VM y 3 GB para cada VM de producción).

Si se usan sistemas de nivel 1 y también hardware virtualizado, se puede conseguir prácticamente el 100 por cien de compatibilidad de dispositivos. Mi equipo portátil, por ejemplo, tiene tres dispositivos que no tienen controladores x64 disponibles. Todos ellos parecen dispositivos de tipo plano anterior que no son fundamentales y el rendimiento del sistema es correcto sin su presencia. Curiosamente, una instalación de Windows Vista RC1 x64 tuvo como resultado exactamente la misma compatibilidad de dispositivos; aunque con el logotipo de apto para Windows de mi sistema, seguramente el proveedor suministrará en poco tiempo incluso estos controladores que faltan.

Debido a que nuestro uso de los sistemas se limita principalmente a Microsoft Office, Visual Studio® y diversas herramientas adicionales que se usan en el proceso de desarrollo y creación, no contamos con muchas aplicaciones heredadas que ocasionen problemas de compatibilidad en la migración. Mientras que una parte importante de nuestra empresa usa versiones de 32 bits de Windows, hemos iniciado la migración hacia 64 bits con nuevo hardware y ha resultado ser relativamente sencillo.

Implementación y migración a x64

Existen algunas consideraciones a tener en cuenta en lo que respecta a la implementación. Microsoft ofrece una versión de Windows Preinstallation Environment (Windows PE) específicamente para la arquitectura x64. Sin embargo, desde que existe paridad x86 en sistemas x64, puede querer usar Windows x86 PE para su implementación, en particular, si está usando una solución de creación de imágenes. Si implementa Windows XP con una instalación desatendida, Windows PE tendrá que ser específico para la arquitectura, ya que winnt32.exe debe ejecutarse en la misma arquitectura que se está implementando. Debido a que Windows PE no tiene un nivel de compatibilidad de 32 bits y winnt32.exe en x64 es una aplicación de 64 bits, Windows de 32 bits requiere Windows PE de 32 bits. Lo mismo se aplica a las versiones de 64 bits de Windows, que requieren Windows PE de 64 bits.

En este sentido, con los Servicios de instalación remota (RIS) es diferente, y por ello en Pluck usamos RIS. RIS, empezando con Windows Server 2003 SP1, también puede implementar x64 así como x86 o las arquitecturas de Itanium de Windows. Cuándo un sistema x64 se conecta a un servidor de RIS, el servidor (en la configuración predeterminada) ofrecerá imágenes RISetup o RIPrep x86 y x64. RIS también se puede configurar para que ofrezca imágenes x86 de clientes x64 o imágenes x64 exclusivamente. Se ofreció esta selección como valor predeterminado para proporcionar el mejor uso posible con hardware x64.

Tenga en cuenta que aún no he mencionado las actualizaciones. Tengo mis buenos motivos. Desafortunadamente, la actualización de la totalidad de un sistema operativo de x86 a x64 es una tarea masiva. Por este motivo y debido a la limitada implementación de Windows XP Professional x 64 Edition, no puede actualizar a Windows XP x64 desde ninguna versión x86, ni tampoco puede actualizar desde ninguna versión de Windows XP (x86 o x64) a Windows Vista x64. Windows Vista en sistemas x64 es, tal como antes lo fue Windows XP Professional x64 Edition, un producto de instalación limpia únicamente. Por este motivo, muchas empresas deciden migrar a x64 sólo cuando es necesario realizar una actualización de hardware; una estrategia similar a la que se espera que emprendan muchas empresas con Windows Vista (un cambio doble, lo que tiene más sentido).

Pero esto no quiere decir que las personas o las empresas que pasen de Windows x86 a Windows x64 no tengan herramientas fácilmente disponibles: sí que las tienen. Las versiones de la Herramienta de migración del estado del usuario (USMT) para Windows XP y Windows Vista no se han ampliado para ser compatibles con la migración (frente a una actualización en banda del sistema operativo) desde una instalación de Windows a otra. Este es el método predominante que usan hoy en día la mayoría de las empresas para implementar Windows a pesar de todo (empezando desde cero pero manteniendo todos los datos, incluso en el mismo equipo), de forma que usar el mismo mecanismo para cambiar a Windows en una arquitectura totalmente nueva no debería representar más problemas que antes.

Conclusión

A pesar de que la migración gradual a x64 de nuestra pequeña empresa pueda resultar considerablemente más fácil que el proceso de migración de envergadura al que se enfrentan las empresas más grandes, todos los profesionales de TI deben empezar a considerar un posible cambio a la arquitectura x64. La realidad es que aunque la arquitectura x86 y la versiones nativas x86 de Windows seguirán estando presentes en los próximos diez años, la arquitectura x64 es ciertamente el futuro de la informática en la empresa. Con el cambio completo de Microsoft a la compatibilidad con x64 para Exchange Server y otros productos, debería empezar a ver dónde encajarían los sistemas x64 en su arquitectura y cuál es su sitio en su plan de migración a Windows Vista, esté o no usando actualmente Windows XP o Windows Server 2003 de forma nativa en sus sistemas x64.

Wes Milleres un administrador de desarrollo de Pluck (www.pluck.com) en Austin, Texas. Anteriormente, trabajó en Winternals Software y en Microsoft como administrador de programas y administrador de producto para Windows. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.