Compatibilizacion de aplicaciones para migrar a Windows 7 – parte 3
En la tercer entrega de la serie de posts sobre compatibilización de aplicaciones que se llevará adelante en un proyecto de Migración a Windows 7 con la metodología desarrollada por Wetcom en este caso profundizaremos sobre el segundo filtro de la remediación aplicativa, remediación de aplicaciones con shims de Microsoft.
De acuerdo a nuestra experiencia en proyectos de migración a Windows 7 la mitigación de incompatibilidad aplicativa tiene los siguientes filtros definidos:
- Upgrade a una versión superior
- Remediación por medio de SHIMS de Microsoft
- Buscar una aplicación alternativa
- Virtualización de la aplicación
- Ejecución de la aplicación de la aplicación bajo Windows XP Mode
De lo que va de la serie claramente este es el post más técnico donde vamos a cubrir la remediación de aplicaciones por medio de shims.
¿Qué es un shim?
Un shim es código que se pone frente al sistema operativo buscando interceptar las llamadas que se hacen desde una aplicación hacia el sistema operativo. Las llamadas al sistema operativo se realizan por medio de la Import Address Table (IAT), sin un shim de por medio la cadena de una llamada de una aplicación al sistema operativo se vería como esto:
Debido a las modificaciones de código fuente de Windows entre las diferentes versiones del sistema operativo es que nos encontramos en que algunas funciones no son compatibles con las aplicaciones con as que acostumbramos trabajar. En ese momento es en que entran en juego los shims.
¿Cómo funciona un shim?
Básicamente un shim lo que hace es recibir las llamadas que hacen las aplicaciones al sistema operativo y en lugar de dejar que la IAT lo entregue directamente al kernel de Windows lo recibe él mismo presentando una variación de la función llamada.
¿Implicancias de un shim?
Para Windows un shim no es otra cosa que una aplicación, o parte de una aplicación. Por lo tanto el shim no tiene manera de “saltar” los mecanismos de seguridad establecidos en el sistema operativo y en caso de necesitar correr la aplicación+shim en un sistema con UAC activado se deberá ejecutar el mismo con permisos elevados. Esto garantiza no bajar el nivel de seguridad establecido a nivel de sistema operativo.
Lo que el shim presenta a la aplicación puede llegar a ser ingresado dentro de la aplicación eliminando la necesidad de el shim en si mismo. Esto es válido cuando somos los desarrolladores de una aplicación in-house pero no cuando la aplicación es de terceros y no tenemos acceso al código fuente de la misma.
¿En que casos usar shims?
- La empresa compró la aplicación a un fabricante que ya no está presente en el mercado o no liberará una nueva versión de la misma.
- La empresa desarrollo una aplicación pero el equipo de desarrollo no llega a modificar el código fuente de la misma al momento de ejecutar la migración.
- El fabricante de la aplicación desarrollará una aplicación compatible con el nuevo windows pero, para no detener la migración, se ofrece a los usuarios una versión “shimeada” de la misma.
En otro post veremos como se desarrollan los shims, el proceso de generación e implementación en Windows. Para mayor información oficial de Microsoft sobre shims siga el enlace.
¿Te quedan dudas sobre como se implementa un shim? déjanos un comentario.
Para conocer más sobre la metodología de Wetcom para la migración de Windows 7 o remediación de aplicaciones utilice el formulario de contacto y un representante se comunicará a la brevedad.