Skip to main content

Comprensión de la compatibilidad de aplicaciones

Hay varias razones por las que una aplicación que funcionó en versiones anteriores de Windows podría presentar errores en Windows 8, a menos que actúe para solucionar la aplicación. La cantidad de aplicaciones de este tipo que podría encontrar depende, en gran medida, de la versión de Windows que use actualmente. La transición de Windows XP a Windows Vista fue, sin lugar a dudas, una de las más difíciles en la historia reciente. Windows 7, en comparación, era altamente compatible con Windows Vista y Windows 8 se está volviendo muy compatible con Windows 7. Así que, si en este momento usa Windows Vista o superior, las posibilidades están a su favor, ya que le será mucho más sencillo migrar sus aplicaciones a Windows 8. Si todavía está usando Windows XP (o, por increíble que parezca, una versión anterior de Windows), es probable que tenga que esforzarse más. Pero, como lo han demostrado innumerables clientes, es un desafío superable que se puede vencer cuando se guía por el enfoque adecuado en cuanto a la compatibilidad de las aplicaciones.

¿Por qué las aplicaciones se interrumpen cuando se migra a un sistema operativo más actualizado? A veces se debe a que una aplicación asumía una dependencia del comportamiento indocumentado del sistema operativo, ya sea porque el desarrollador usó intencionalmente una API no documentada o porque confió involuntariamente en un comportamiento que resultó ser más una coincidencia que una promesa. (Con lo masiva que es la documentación de Microsoft Developer Network (o MSDN) actualmente, es demasiado difícil entender por completo todos los comportamientos posibles del sistema operativo). Algunas veces se retiran características y comportamientos, lo que a menudo se debe a problemas de seguridad, pero que también puede ser el resultado de la falta de adopción de mercado o el reemplazo por tecnología superior. Lo que resulta frustrante es que la causa más frecuente del error en la compatibilidad de las aplicaciones es una comprobación de la versión. Eso significa que la aplicación comprueba la versión del sistema operativo y luego elige producir el error de manera intencional, si descubre una versión diferente a la que eligió para ejecutarse. Básicamente, la aplicación no permite que la ejecute en un nuevo sistema operativo, aunque con ello funcionara a la perfección.

Si está interesado en obtener información más detallada, le ofrecemos la Guía de compatibilidad de Windows 8 y Windows Server 2012, para que le ayude a comprender los cambios en la compatibilidad. Sin embargo, el público objetivo de la guía son los desarrolladores que escriben el código. En vez de eso, este artículo toma en cuenta la perspectiva de los profesionales de TI que intentan migrar sus organizaciones a Windows 8. Aquí analizamos la motivación tras los cambios realizados en Windows 8, así como el posible impacto de los mismos.

En este artículo:


Aumentar la confiabilidad

A medida que Microsoft continua mejorando la seguridad y confiabilidad general del sistema operativo, nos dimos cuenta de que no se podría realizar ninguna de estas inversiones en su totalidad mientras la mayoría de los usuarios se ejecutaran como administradores locales. Por supuesto, este ha sido el caso por motivos históricos. MS-DOS, y las primeras versiones de Microsoft Windows, no manejaban el concepto de equipos compartidos ni de comprobaciones de seguridad. Mientras Windows NT presentaba una fuerte infraestructura de seguridad, también presumía de su compatibilidad con las aplicaciones existentes para MS-DOS y Windows, que nunca se diseñaron para un sistema operativo seguro y de varios usuarios. Muchos clientes confiaron en estas aplicaciones, lo que dio como resultado que los usuarios quedaran como administradores locales. Sin embargo, es mucho más costoso administrar a los usuarios administradores que a los usuarios estándar y clientes en todo el mundo pedían a gritos una forma de hacer que un alto porcentaje de sus usuarios fueran estándar. Por supuesto, algunos tuvieron éxito, pero casi siempre consistía en un proceso costoso y difícil y se necesitó hacer más de una modificación en la configuración de seguridad del sistema operativo para admitir aplicaciones que dependen de los privilegios de administrador.

En Windows Vista, presentamos la característica control de cuentas de usuario (UAC) para terminar de una vez por todas con el ciclo de los administradores locales que se encargaban de aplicaciones que dependían de derechos de administrador local y que, por lo tanto, requerían más administradores locales. Finalmente, los clientes podrían experimentar una reducción en el costo total de las operaciones (TCO), junto con una postura de seguridad superior que se logra en un entorno de usuario estándar. Esta característica, principalmente, era una de compatibilidad. Proporcionaba soluciones automatizadas para varios desafíos de compatibilidad, como pasar datos de archivos y del registro a ubicaciones protegidas o errores en programas de instalación que dependen del permiso del administrador para instalarse en ubicaciones globales. También brindaba opciones de corrección adicionales que se podían aplicar manualmente a las aplicaciones, para solucionar problemas de compatibilidad que podrían surgir por las aplicaciones que se ejecutaban bajo permisos de usuario estándar.

Además de corregir aplicaciones de terceros, el control de cuenta de usuario mejoró la experiencia de los usuarios estándar de diferentes maneras. Por ejemplo, agregamos la capacidad de que los usuarios estándar pudieran cambiar su zona horaria en el momento de viajar (una queja habitual entre los clientes que consiguieron implementar usuarios estándar en Windows XP o anterior de manera satisfactoria). También presentamos una nueva infraestructura de seguridad, basada en la confianza de la aplicación y en la identidad de usuario, lo que nos permitía implementar un comportamiento de espacio aislado. Los software como las aplicaciones de Internet Explorer y Microsoft Office 2010 aprovecharon estos recintos para mejorar la defensa a fondo de su seguridad. Windows 8 amplía esta infraestructura de seguridad basada en la confianza aun más, gracias a los contenedores de aplicación.

Observe que debido a que UAC proporciona la infraestructura de seguridad para los contenedores de aplicación, si lo deshabilita no podrá ejecutar las aplicaciones de la Tienda Windows. Por esta razón, los clientes que elijan deshabilitar UAC para Windows Vista o Windows 7, ahora deben considerar dejarlo habilitado para Windows 8 y resolver los problemas de compatibilidad con los usuarios estándar, los que probablemente hayan causado que dichos problemas deshabilitaran UAC en primer lugar.

UAC proporciona beneficios tangibles, incluso para los administradores locales. Al ejecutar administradores locales con credenciales de seguridad, muy similares a los usuarios estándar, los usuarios que tengan una necesidad real de mantener derechos de administrador local, como es el caso de desarrolladores y administradores de TI, pueden trabajar en un entorno en el que el software y las secuencias de comandos que creen no generen a su vez dependencias accidentales adicionales en los derechos de administrador local. Este cambio ya ha tenido un gran impacto en los proveedores de software independientes (ISV), quienes ahora crean software que en la mayoría de los casos se ejecuta a la perfección con derechos de usuario estándar, gracias a UAC. Tiene el mismo impacto dentro de la empresa.

En Windows Vista y posterior agregamos, además, una característica llamada Protección de recursos de Windows (WRP) y que aprovecha otra extensión de la infraestructura de seguridad de Windows: la capacidad de asegurar recursos para que se tenga acceso a ellos solo desde un servicio en especial, en lugar de la identidad de la cuenta bajo la que se ejecuta el servicio. Esto hace que sea difícil que una aplicación (casi siempre se trata de un instalador que incluyó todas las dependencias DLL en el momento de su creación) cree de manera accidental una copia de una versión anterior de un archivo DLL del sistema de Windows NT 4.0 (por ejemplo: shell32.dll), sobre la copia que usa Windows 8. Como sabe, eso podría tener horribles resultados. En vez de eso, solo el servicio que se encarga de Windows Update (el servicio instalador de módulos de Windows) puede modificar estos archivos de forma predeterminada. Y por supuesto, también proporcionamos opciones de corrección para esas aplicaciones, para que el error de escribir en estos archivos no produzca un error irreparable en sus aplicaciones.

Volver al inicio


Mejorar la seguridad

Casi por definición, mejorar la seguridad implica evitar que ocurran ciertas cosas y bloquear a quienes quieran llevarlas a cabo. Sin embargo, es posible que las aplicaciones dependan de la capacidad para realizar algunas de estas cosas, en especial las aplicaciones antiguas, que probablemente se desarrollaron antes de que ciertas personas aprendieran a explorar una capacidad para que haga cosas malas. En algunos casos agregamos una capacidad para que bloquee un comportamiento que antes no existía. En otros casos, modificamos los valores predeterminados para bloquear el comportamiento de manera predeterminada, en los casos en que antes permitimos el comportamiento como predeterminado y le solicitamos que participara para bloquearlo.

El modo protegido de Internet Explorer, por citar un ejemplo, proporciona un espacio aislado de seguridad que restringe en gran manera la capacidad de que los controles de ActiveX, hospedados en una página, tengan acceso al sistema operativo. Desde Internet Explorer 8 en adelante, el modo protegido está habilitado de manera predeterminada en las zonas de Internet y de sitios restringidos. Muchos de los clientes que tienen una dependencia de los controles de ActiveX descubren que sus tamaños internos no se están distribuyendo bien en la zona de intranet local (que deshabilita el modo protegido de manera predeterminada) y, por consiguiente, estas aplicaciones parecen menos compatibles.

Microsoft presentó la compatibilidad con sistemas operativos para la prevención de ejecución de datos (DEP) con Windows XP SP2. DEP es una característica de protección de memoria compatible tanto con el software como con el hardware, lo que reduce la capacidad de que el malware ataque al sistema con técnicas como los desbordamientos de búfer. Ayuda a protegerse contra códigos malintencionados que estén ingresando a través de los puntos de entrada de datos de una aplicación. Sin embargo, Windows 8 mantiene DEP configurado para participar con el fin de maximizar la compatibilidad. Las nuevas aplicaciones de la Tienda Windows optarán por DEP, pero solo se aplicarán restricciones DEP a las aplicaciones de escritorio existentes si participan en esta característica. Internet Explorer tiene la capacidad de participar en DEP desde Internet Explorer 7 y la habilita de forma predeterminada desde Internet Explorer 8. Esto significa que a los controles de ActiveX que generan y ejecutan un código de manera dinámica, pero que no han podido marcar su memoria como ejecutable, se les generará una excepción (la que bloqueará a la aplicación si esta no la controla) cada vez que intente ejecutar este código.

El aislamiento de la sesión 0 sigue siendo un desafío para los clientes que migran desde Windows XP o de versiones anteriores en el momento de cambiarse a Windows 8. Un servicio de Windows se ha ejecutado en la sesión 0 desde siempre y hasta el día de hoy. En Windows XP y en versiones anteriores el primer usuario que inicia sesión en el equipo también se ejecuta en la sesión 0. Este enfoque era más eficaz cuando los recursos de equipo eran mucho más limitados. Sin embargo, a pesar de ser mezquinos con los recursos, esto expone cierta área de seguridad, ya que las aplicaciones que por lo general se ejecutan con privilegios del sistema local cohabitaban con otras aplicaciones que se ejecutan con menos privilegios; esto brindó una oportunidad tentadora para la elevación de privilegios. En consecuencia, los usuarios ya no inician sesión en la sesión 0. Esta sesión es solo para servicios. A menudo, las aplicaciones de servicio que esperan comunicarse con el usuario o con sus programas de manera directa tienen que encontrar nuevos mecanismos para lograrlo.

Continuamos agregando características de seguridad a Internet Explorer, ya que es la parte del sistema operativo que se conecta con más frecuencia a los posibles agentes malintencionados. Por ejemplo, la característica de Protección de rastreo que tienen Internet Explorer 9 e Internet Explorer 10 ayuda a los usuarios a proteger su privacidad al bloquear agentes de rastreo enumerados. Sin embargo, varios de los mismos sitios que rastrean el comportamiento en línea también proporcionan una funcionalidad de aplicación web, por lo que es posible que varias secuencias de comandos no se puedan cargar y ejecutar mientras permanezcan en un dominio bloqueado por una de sus listas de protección de rastreo.

De manera similar, la característica de filtro SmartScreen de Internet Explorer le ayuda a protegerse contra descargas malintencionadas. En Internet Explorer 8, el filtro SmartScreen lo protegía de una lista de descargas malintencionadas conocidas. Desde Internet Explorer 9, el filtro SmartScreen se mejoró para agregar reputación, lo que hacía necesario que las descargas crearan una reputación antes de poder clasificarlas como buenas, de otra forma, se generaba una alerta que indicaba que la descarga era nueva y que por lo tanto, no se sabía si era buena o no. Windows 8 toma este concepto y lo lleva al sistema operativo, lo que ayuda a protegerlo contra las descargas que no han establecido una reputación positiva, sin importar el explorador que se use para obtenerlas. Esto puede provocar un error en algunos escenarios en los que descarga archivos ejecutables sin firmar con frecuencia o en los que realiza descargas ocasionales que no cuentan con la cantidad suficiente como para desarrollar una reputación de aplicación.

Volver al inicio


Mejorar el rendimiento y las capacidades

Uno de los cambios que más mencionan los clientes empresariales cuando se migra a la última versión de Windows es la habilidad para aprovechar las capacidades y el rendimiento de un sistema operativo de 64 bits. Aunque la versión de 64 bits brinda la capacidad de ejecutar aplicaciones que necesitan acceso a enormes cantidades de memoria y le da la capacidad de aprovechar una gran cantidad de RAM, hay un posible impacto en la compatibilidad. Aunque Windows de 64 bits puede ejecutar sus aplicaciones existentes de 32 bits, no puede ejecutar sus aplicaciones existentes de 16 bits. Tampoco es compatible con sus controladores de dispositivos existentes de 32 bits. Si tiene un dispositivo que no cuenta con un controlador de dispositivo de 64 bits o si tiene aplicaciones de 16 bits que son esenciales, tendrá que ejecutarlas en un sistema operativo de 32 bits.

Otro posible impacto a la empresa que ejecuta Windows de 64 bits es el impacto en las aplicaciones .NET que interoperan con código nativo a través de la interoperabilidad COM o la interoperabilidad de P/Invoke. La configuración predeterminada del compilador para las aplicaciones .NET se llama "Any CPU", lo que significa que estas aplicaciones se convertirán en aplicaciones de 64 bits en un sistema operativo de 64 bits y en aplicaciones de 32 bits en un sistema operativo de 32 bits. Si llaman al código nativo, este necesitará ser del mismo tipo (de 64 o 32 bits) que la aplicación de llamada. Así que, cuando la aplicación llama al código nativo y este está compilado como un código de 32 bits, la llamada no podrá cargar ese DLL. Afortunadamente, este es un problema relativamente fácil de resolver, se puede modificar la configuración del compilador o modificar el ejecutable mediante la utilidad CorFlags. Vale la pena mencionarlo debido a la frecuencia con la que afecta a las aplicaciones del cliente empresarial.

Windows Vista presentó un nuevo modo de presentación llamado Administrador de ventanas de escritorio (DWM). El DWM cambió el modelo histórico en el que las aplicaciones se procesaban directo en la memoria en pantalla y provocó que las aplicaciones se procesaran en los mapas de bits fuera de pantalla, los que después el DWM compone para crear la presentación que ven los usuarios. Se obtienen importantes beneficios para el rendimiento y para la experiencia del usuario al seguir este enfoque. Sin embargo, varios tipos de aplicaciones no fueron compatibles con el DWM. Para la empresa, el mayor impacto ocurrió en las aplicaciones remotas, que a menudo usan unidades reflejadas para redireccionar la presentación. Desde Windows 8 ya no se puede deshabilitar el DWM, ya que ahora es fundamental para la experiencia del sistema operativo. Aunque hemos hecho todo lo posible por mantener la mayoría de las aplicaciones en funcionamiento, es posible que aquellas que sigan usando enfoques históricos no siempre funcionen.

Un aspecto clave del rendimiento para los usuarios móviles es la vida útil de la batería. Con el nuevo modelo para aplicaciones de la Tienda Windows en Windows 8, las aplicaciones ya no solo son de pantalla completa y envolventes, sino que también se suspenden cuando no están visibles. Como resultado de esto, no consumen ciclos de CPU y por lo tanto, no agotan la batería. Sin embargo, e históricamente, las aplicaciones existentes se ejecutan siempre, lo que consume tanto CPU como batería desde el momento en que se inician hasta el momento en que se cierran. Para ayudar a aumentar la vida útil de la batería (que es lo que esperan los usuarios) aun con aplicaciones de escritorio, Windows 8 adopta ciertas medidas para acelerar las aplicaciones de servicio existentes, modificando la cantidad de CPU que se les permite usar, y para suspender las aplicaciones interactivas cuando no estén en uso y cuando la pantalla esté apagada. Aunque esto cumple con las expectativas del usuario (cuando presiona el botón de encendido en su dispositivo móvil cuenta con que no continuará ejecutándose al máximo), podría ser un problema para las aplicaciones que no prevén su suspensión. Por fortuna, este impacto es casi mínimo.

Volver al inicio


Posibilidades de uso avanzadas

Dado que las visualizaciones del equipo contienen cada vez más píxeles en pantallas cada vez más pequeñas, es importante cambiar la visualización para que todo sea más grande pero que al mismo tiempo se ejecuten con las capacidades no interpoladas de la pantalla. Windows tiene una funcionalidad con configuración elevada de ppp compatible con varias versiones y que mejora con cada versión posterior. Desde Windows 7 la compatibilidad con la configuración elevada de ppp era lo suficientemente sólida como para comenzar a detectar y a dejar predeterminada una configuración de PPP basada en la pantalla. Sin embargo, siguen habiendo algunas aplicaciones para las que la configuración de PPP alta son un problema y si una parte importante de los dispositivos que tiene pensado implementar se beneficiarían con dicha configuración, entonces, probar sus aplicaciones en este escenario es una inversión que vale la pena.

Volver al inicio


Eliminar componentes heredados

Aunque hacemos lo mejor posible para conservar la compatibilidad con las aplicaciones heredadas, hay algunas situaciones en las que admitir cierta característica ya no es factible, ya sea porque bloquea la capacidad que tenemos de proporcionar un reemplazo superior o porque tiene errores que nos impiden alcanzar nuestras metas en cuanto a rendimiento, confiabilidad o seguridad. Cuando este es el caso, descartamos la característica. Aunque no es una lista exhaustiva, hay algunos elementos obsoletos que han causado ciertas preocupaciones en cuanto a la compatibilidad en la empresa y que mencionaremos aquí.

Desde Windows Vista, eliminamos la compatibilidad para los controladores de impresora de modo kernel. Esto se debe a motivos de confiabilidad, un error en el controlador de modo kernel genera una pantalla azul para todo el sistema, mientras que un error en un controlador de modo usuario solo provocan el bloqueo del controlador. En general, hemos pasado la mayor cantidad de funcionalidad del modo kernel posible, en especial cuando la confiabilidad es un problema, sin comprometer nuestra capacidad de cumplir con los objetivos de rendimiento. Aunque la mayoría de los clientes ya no usan impresoras con controladores de modo kernel, si nos encontramos con ellos de vez en cuando en impresoras y trazadores avanzados que, debido a su precio, tienen un tiempo medio de vida más largo que el promedio. La mayoría de las veces, nos enfrentamos a desafíos con impresoras virtuales, como impresoras que generan archivos PDF; a menudo, las versiones anteriores de estas impresoras aprovechan los controladores de modo kernel que ya no se ejecutarán.

Además, hemos retirado de forma gradual los archivos de WinHelp en formato de archivo de ayuda. Este formato de archivo se presentó en 1990 para Windows 3.0. Nosotros proporcionamos Ayuda de HTML, su sucesor, en 1997 con Internet Explorer 4.0. Aunque seguimos admitiendo archivos WinHelp, con Windows Vista la preocupación de un área de seguridad adicional nos impulsó a eliminar WinHelp del sistema operativo. Los contenidos del archivo de ayuda eran tan eficaces en este formato que eran equivalentes a un archivo ejecutable. Sin embargo, dado el gran volumen del contenido de WinHelp que se generó por más de dos décadas de soporte, seguimos proporcionando compatibilidad descargable para Windows Vista y Windows 7 y lo seguiremos haciendo para Windows 8.

Los medios por los que inicia sesión en Windows se han extendido por mucho tiempo, pero el mecanismo que usamos históricamente permitía que funcionara solo un proveedor a la vez. Este mecanismo necesitaba que los proveedores desarrollaran todo el código y que crearan toda la experiencia de usuario para el proceso de inicio de sesión. Desde Windows Vista reemplazamos este modelo con el modelo de proveedor de credenciales, que necesitaba que los desarrolladores implementaran la parte de la autenticación que era diferente a la proporcionada y también permitía que varios proveedores trabajaran en conjunto. Sin embargo, este cambio a la arquitectura requiere que se vuelva a escribir cualquier aplicación que proporcione medios alternativos para iniciar sesión en Windows XP o anterior.

Volver al inicio


Resumen

En este artículo, exploramos algunas de las inversiones realizadas en Windows que podrían tener un efecto adverso en la compatibilidad para sus aplicaciones existentes. La compatibilidad ha sido por mucho tiempo uno de los principios en el desarrollo de Windows y siempre tomamos muy en serio las regresiones de compatibilidad. Afortunadamente, este artículo explica algunas de las motivaciones tras estos cambios y le puede ayudar a entender los compromisos que tenemos que hacer.

Aunque a menudo la transición de Windows XP (o anterior) a Windows 8 tiene una frecuencia de errores del 20 por ciento o superior (si usa un software más antiguo y si ejecuta escritorios de administrador local) hay varias opciones de corrección disponibles para solucionar la mayoría de estos errores, lo que le permite tener más tiempo para enfocarse en las aplicaciones que necesitan intervenciones más importantes. La frecuencia de errores de Windows Vista o Windows 8 ha demostrado estar dentro de los dígitos más bajos (el principal culpable es la comprobación de versión no modificable). Así que, debe ser capaz de ampliar y maximizar las inversiones de activos de software aun más con Windows 8. Le deseamos mucha suerte en sus esfuerzos de compatibilidad de aplicaciones.

Volver al inicio

Tareas principales

Acerca del autor

Fotografía de Chris JacksonChris Jackson, conocido como " El chico de la compatibilidad de aplicaciones" es consultor principal y el líder técnico del equipo de Experiencia con aplicaciones (AE) SWAT de Windows. Como experto ampliamente reconocido en el campo de la compatibilidad de aplicaciones, Chris creó la documentación técnica, el entrenamiento y las ofertas de servicios usados dentro y fuera de Microsoft, basados en años de experiencia práctica con clientes empresariales y proveedores de software independientes.

Chris es autor o coautor de varios artículos técnicos y de artículos sobre la compatibilidad de aplicaciones, además de contribuir con TechNet Magazine. También es un orador destacado en los principales congresos de la industria alrededor del mundo, inclusive TechEd, IT Forum y Microsoft Management Summit.

Recursos relacionados

Manténgase informado

Microsoft está realizando una encuesta en línea para comprender su opinión del sitio web de. Si decide participar, se le presentará la encuesta en línea cuando abandone el sitio web de.

¿Desea participar?