Preparando nuestras aplicaciones para Windows 7

Se acerca el lanzamiento de Windows 7, el próximo sistema operativo de Microsoft. La fecha de lanzamiento oficial será el 22 de Octubre, pero desde hace algunos meses podemos conseguir una copia si disponemos de una subscripción de TechNet o MSDN.

Windows 7 es tecnológicamente una evolución de Windows Vista. Si nuestra aplicación funcionaba con Windows Vista, perfecto, funcionará también con Windows 7 (aún así no hay que tomarse esto al pie de la letra y lo mejor será que hagamos las pruebas de compatibilidad pertinentes en un sistema Windows 7 para estar 100% seguros).

En caso de que nuestra aplicación no lo sea, lo mejor es que empecemos a probarla cuanto antes, y empecemos a conocer este nuevo sistema cuanto antes para estar preparados. Dos de los cambios que más afectan a nuestras aplicaciones y que fueron introducidos con Windows Vista y continúan presentes en Windows 7 son:

Control de Cuentas de Usuario (UAC)
Aislamiento de la Sesión 0

Control de Cuentas de Usuario

El Control de Cuentas de Usuario es una tecnología de seguridad introducida en Windows 7 y que reduce los permisos de las cuentas del sistema, incluyendo la cuenta Administrador, haciendo que todos los usuarios se ejecuten con permisos de una cuenta de Usuario estándar. Cuando el sistema detecta que un usuario (sea Administrador o no) intenta modificar alguna de las ubicaciones protegidas, solicitará confirmación al usuario para finalizar la acción. Más información sobre el control de cuentas de usuario aquí.

¿En que afecta esto a nuestras aplicaciones? Debemos recordar siempre que nuestra aplicación se ejecuta con los permisos de la cuenta de usuario que la ha iniciado. Por lo tanto si se reducen los permisos de la cuenta, se reducen los permisos de nuestra aplicación.

Todavía hoy, muchas aplicaciones intentan escribir información en ubicaciones como C:\Archivos de Programa\MiAplicacion o en el registro dentro de HKEY_LOCAL_MACHINE (HKLM). Estas y otras son ubicaciones protegidas por el sistema y solo una cuenta con permisos de Administrador puede escribir en ellas.

¿Esto quiere decir que nuestra aplicación dejará de funcionar inmediatamente en Windows Vista o Windows 7 por escribir en dichas ubicaciones? Por desgracia no, nuestra aplicación parecerá funcionar correctamente, sin embargo, en dependencia del diseño de nuestro aplicación, el funcionamiento de la misma puede ser erróneo. Algunos de estos errores pueden ser:

La aplicación escribe correctamente en C:\Archivos de Programa\MiAplicacion\Settings.ini pero al ejecutarla con otro usuario no encuentra la información almacenada en Settings.ini

La aplicación crea una clave del registro en HKLM pero al intentar leerla falla al no encontrar la clave creada.
La aplicación crea un archivo en c:\Archivos de Programa\MiAplicacion\MiArchivo.dat pero al intentar leerlo no encuentra dicho archivo.

Cuando una aplicación sufre de estos síntomas, indica que el sistema le está aplicando una técnica de compatibilidad llamada Virtualización UAC. El sistema detecta que la aplicación no está diseñada para UAC y por lo tanto redireccionará todas las llamadas a las ubicaciones protegidas, creando un sistema de archivos virtual donde la aplicación si tiene permisos. Es posible que nuestra aplicación parezca funcionar correctamente gracias a la Virtualización UAC sin embargo es muy probable que tarde o temprano aparezcan estos síntomas.

Para prevenir estas situaciones podemos detectar si la Virtualización UAC está siendo aplicada en nuestra aplicación con la utilidad Process Monitor de SysInternals:

Detectando la Virtualización UAC

En esta imagen vemos que la operación de escritura de nuestra aplicación en C:\Archivos de Programa(x86)\AclBrokenApp\SomeFile.txt no ha fallado, sino que el sistema la ha marcado como REPARSED y ha generado una operación adicional que escribe nuestro archivo en:

C:\Users\NombreUsuario\AppData\Local\VirtualStore\Archivos de Programa(x86)\AclBrokenApp\SomeFile.txt.

El sistema está aplicando aquí Virtualización UAC, lo que provoca que la operación de escritura de nuestra aplicación sea redireccionada a una ubicación donde si tiene permisos para escribir.

Esto provocará que nuestra aplicación posteriormente no sea capaz de encontrar el archivo ya que su ubicación ha sido modificada. La misma técnica se aplica cuando nuestra aplicación escribe en una ubicación protegida del registro como HKLM.

Desactivando la Virtualización UAC

Para corregir el funcionamiento anterior, el primer paso es hacer que nuestra aplicación falle cuando intenta escribir en ubicaciones protegidas. Para ello debemos notificar al sistema de que nuestra aplicación está preparada para UAC, lo que provocará que Windows desactive la Virtualización UAC para nuestra aplicación. Para ello necesitaremos incluir un archivo de manifiesto en la aplicación, con una directiva UAC.

El manifiesto puede estar incrustado dentro del ejecutable de la aplicación o ser un archivo independiente con el mismo nombre que nuestra aplicación: MiAplicacion.exe.manifest.

Para saber más acerca del manifiesto UAC aquí.

Eligiendo las ubicaciones correctas

Una vez desactivada la virtualización, nuestra aplicación fallará cada vez que escribimos en una ubicación protegida. Ahora que tenemos el control del comportamiento de nuestra aplicación, debemos de modificarla para utilizar las ubicaciones adecuadas. Para ello es recomendable utilizar el método System.Environment.GetFolderPath, en lugar de codificar manualmente las rutas. Este método recibe una enumeración dónde podemos especificar de forma segura una ruta del sistema. Los valores que podemos utilizar son, según como queremos utilizar la información almacenada:

Environment.SpecialFolder.CommonApplicationData: Para almacenar información que queremos se comparta entre múltiples usuarios, como la configuración, logs, etc.
Environment.SpecialFolder.LocalApplicationData: Para almacenar información específica al usuario. Esta ubicación es sólo local.
Environment.SpecialFolder.ApplicationData: Para almacenar información específica al usuario. Esta ubicación se incluye en un perfil de Roaming.

Aislamiento de la Sesión 0

Hasta ahora en los sistemas Windows hasta Windows XP, la denominada Sesión 0 ha sido siempre la primera sesión que un usuario iniciaba en el sistema. Esto provocaba que servicios con un conjunto de permisos reducido compartiesen entorno con aplicaciones con permisos más elevados, lo que significaba un riesgo de seguridad:

Modelo de Sesión de Windows XP

Desde Windows Vista, por motivos de seguridad, los servicios quedan aislados de la sesión del usuario, dónde ahora solo se ejecutarán las aplicaciones. A esto se le denomina Aislamiento de la Sesión 0:

Aislamiento de sesión en Windows Vista y windows 7

Esta medida de seguridad puede afectar a nuestros Servicios de Windows dónde podremos encontrar situaciones como éstas:

Un servicio que intente interactuar con el escritorio del usuario puede quedarse bloqueado, mostrar un mensaje de mitigación, o un icono en la barra de tareas, solicitando la atención del usuario, aunque el servicio tenga permiso para interactuar con el escritorio.
Un servicio puede no comunicarse con su entorno, los objetos y mensajes compartidos por el servicio no llegan a su destino o no son accesibles.

¿Cómo podemos detectar estas situaciones? Utilizando la herramienta Process Explorer de SysInternals podemos obtener información sobre la sesión en la que se están ejecutando nuestros servicios:

Con Process Explorer podemos conocer la sesión en la que se ejecuta un proceso

Una vez detectado el problema, las soluciones son sencillas de aplicar:

Desde .NET podemos evitar el problema de comunicación con el servicio fácilmente, utilizando WCF, canalizaciones por nombre, o cualquier otro mecanismo como IPC (Inter - Process Communication) como sistema de comunicaciones de nuestro servicio. Este tipo de sistemas de comunicación proporcionan una arquitectura lo suficientemente segura que permite que los mensajes interactúen entre sesiones.

Respecto al problema de la interacción con el escritorio, la solución es también muy sencilla: NO interactuar desde el servicio con el escritorio. Un buen diseño de nuestro servicio nunca iniciará la comunicación con el usuario desde el servicio, si no que esta acción será realizada la inversa, donde una aplicación monitorizará, a través de los sistemas de comunicación mencionados anteriormente, el estado del servicio y notificará al usuario de la necesidad de una intervención manual.

Prevención vs reacción

Pronto nuestros clientes empezarán a tener equipos con Windows 7, y muy pronto, en dichos equipos se instalará alguna de nuestras aplicaciones. Por lo tanto, cuanto antes empecemos a realizar pruebas de compatibilidad antes podremos actualizar nuestras aplicaciones, para que nuestros clientes puedan seguir trabajando con ellas sin problemas.

El paso de Windows XP y Windows Vista a Windows 7 es un paso sencillo y que no debe causar problemas, sin embargo, es nuestra responsabilidad asegurarnos de que esto así suceda y que nuestros clientes tengan la mejor experiencia de migración posible.

Recursos Adicionales

Realizado por: Iñaki Elcoro (Departamento de Innovación de Consultec)

Arriba