Como ya lo he mencionado en buena cantidad de artículos anteriores, una de las principales causas por la que una compañía detiene la migración a un nuevo sistema operativo es la compatibilidad de aplicaciones. Generalmente, las empresas tienen una dependencia fuerte por una cantidad pequeña de soluciones que fueron desarrolladas a medida y realizan procesos demasiado importantes como para prescindir de ellas.
Microsoft dispone, desde los tiempos de Windows Vista, de una cantidad de herramientas gratuitas para ayudar a mitigar la gran cantidad de problemas de compatibilidad existentes. Lamentablemente, en LATAM son poco conocidas estas herramientas, así que muchas veces las organizaciones optan por permanecer en una versión x de Windows.
Una de las mejores herramientas, es el Application Compatibility Toolkit (ACT); solución que entre muchas cosas más, nos permite crear Shims o arreglos que interceptan el llamado que hace la aplicación a Windows por algún recurso, y modifica el comportamiento para entregar lo que el software estaba buscando. En otros artículos he documentado el proceso para crear estos arreglos con problemas específicos como Canal+ Yomvi u Oracle 10g, pero hoy empezaré a concentrarme específicamente en la manipulación de los arreglos más comunes a utilizar.
Dicho esto, en este post hablaré lo que más pueda sobre el arreglo de CorrectFilePaths.
Escenario
Supongamos que tenemos una aplicación que intentará escribir unos archivos y te notifica:
Sin embargo, después de aceptar proceder, sucede un típico error inesperado y confuso:
Por supuesto, esta es solo una aplicación que escribí, así que solo muestra un mensaje y su error, pero en aplicaciones de línea de negocio, suele ocurrir algo similar en diferentes facetas, como durante la instalación, su ejecución o en algún módulo. Aún así, en esencia es el mismo problema: No poder crear o abrir archivos en determinado directorio de Windows.
Volviendo a este caso ficticio, mi aplicación está intentado crear el archivo DemoFile.txt pero recibe un error poco descriptivo, y que no sirve para nada. Es trabajo de la persona empezar a lidiar con este problema.
El shim de CorrectFilePaths
Este arreglo, que hace parte de los cientos disponibles en ACT, permite básicamente modificar una ruta existente de archivos y re direccionarla a otra ubicación sin tener que manipular el código de la aplicación de ninguna forma. Así pues, se mantiene la integridad sobre la aplicación, pero se manipula el comportamiento de los archivos que se escriben.
Predeterminadamente, el arreglo contiene varias correcciones predeterminadas; es decir, diferentes rutas que son direccionadas a otra ubicación una vez se aplica, pero además permite agregar nuevas rutas personalizadas así que es bastante flexible.
Consideremos la siguiente ilustración como el comportamiento predeterminado que debería existir entre la aplicación y Windows en este caso:
*Nota: Aquí no estoy detallando dónde escribe la aplicación, porque aunque es importante, el comportamiento general es el mismo.
Ahora, en la siguiente gráfica muestro cuál es el cambio cuando intercede el arreglo (shim):
Como ven, la aplicación pasa a tener un contacto indirecto y no directo con el sistema operativo cuando realiza esta operación. Aquí no se toca código ni nada por el estilo, solo se direcciona a las mismas funciones en un lugar diferente.
*Nota: Si quieren saber un poco más a fondo sobre los Shims, pueden ver este post.
¿Cómo utilizar CorrectFilePaths?
Para poder aplicar esta, o cualquier otra corrección, es necesario instalar el Application Compatibility Toolkit (ACT), que hace parte del ADK disponible desde el sitio Microsoft:
http://www.microsoft.com/en-US/download/details.aspx?id=39982
Una vez descargado, basta con ejecutar el adksetup.exe y en el asistente seleccionar ACT:
De nuevo en el escenario, lo primero que hay que identificar, es dónde está intentando escribir la aplicación que provoca el error. Para esto, no hay otra herramienta mejor que Process Monitor de Sysinternals.
Identificar este tipo de rutas es relativamente sencillo, basta con abrir ProcMon antes de la ejecución de la aplicación, reproducir el problema, presionar las teclas CTRL + F para abrir el cuadro de búsqueda y referenciar el archivo en cuestión; en este caso: DemoFile.txt.
El resultado para esta clase de problemas, sobre todo con aplicaciones hechas a la medida y con cierta antigüedad, es Acceso Denegado (ACCESS DENIED):
La razón de este tipo de resultados, es por los niveles de integridad que existen desde Windows Vista. No entraré en detalle, porque ese tema requiere un artículo completo.
El problema aquí es que el archivo DemoFile.txt está intentando escribir en un directorio protegido por Windows y que un usuario estándar no tiene privilegios, así que esto requeriría elevación, es decir, ser administrador. Como no queremos eso, procedemos a implementar la corrección de CorrectFilePaths para que la aplicación crea que sigue escribiendo en la raíz del disco, pero realmente escriba en un directorio por usuario.
Implementando el shim
Desde el equipo donde está instalado ACT, buscamos en la Pantalla de Inicio el Compatibility Administrator de acuerdo a la arquitectura de la aplicación y lo ejecutamos:
*Nota: Esta consola requiere ejecutarse como administrador, así que pedirá elevación.
Así luce la consola de administración del ACT:
Hacemos clic en el botón Fix de la barra de comandos, o bien clic derecho sobre la base de datos predeterminada, Create New > Application Fix:
En la página de Program Information, rellenamos los datos correspondientes a la aplicación y clic en Next:
En la página de Compatibility Modes, dejamos sin seleccionar nada –no sirven- y clic en Next:
En la página de Compatibility Fixes, buscamos CorrectFilePaths, lo seleccionamos y hacemos clic en Parameters para personalizarlo a nuestra medida:
En la ventana de Options for CorrectFilePaths es donde sale la magia; aquí personalizamos para cada nuevo shim sus respectivas opciones en línea de comandos.
Para el arreglo de CorrectFilePaths, debemos seguir el patrón descrito en las primeras imágenes:
<RutaOriginal>;<NuevaRuta>
Donde <RutaOriginal> es la ubicación en la que la aplicación intenta escribir de forma predeterminada, y <NuevaRuta> es la nueva ubicación por usuario donde queremos que siga escribiendo después de aplicar el arreglo.
Si tenemos en cuenta mi aplicación de ejemplo, trata de escribir en C: según mostró Process Monitor; si yo quiero que escriba en Documentos, el comando quedaría así:
%SYSTEMDRIVE%;%USERPROFILE%Documents
Es muy recomendable utilizar variables de entorno como mostré en el comando anterior, aunque no estrictamente necesario porque también podría haberse referido así:
C:;C:UsersChechoDocuments
Sin embargo, esto quedaría asociado al usuario “Checho” y a letras de unidades específicas. Grave error.
*Nota: El punto y coma (;) es de vital importancia, y debe ir todo pegado.
Como dato adicional, podríamos cambiar incluso el nombre del archivo a escribir; solo es cuestión de referenciar el nombre original y el nuevo nombre, así:
Primero se especifica DemoFile.txt (original) y luego el nuevo nombre, para mi caso: File.txt.
Al hacer clic en OK, la página de Compatibility Fixes debería verse así:
Ya referenciado el arreglo, clic en Next.
*Nota: Con el botón Test Run… podemos probar si el arreglo va a funcionar antes de ser aplicado.
En la página de Matching Information, podemos dejar las opciones predeterminadas y clic en Finish para terminar:
De vuelta en la consola principal, hacemos clic en el botón Save y le asignamos un nombre a la base de datos creada:
Después, indicamos la ruta donde se guardará la base de datos:
*Nota: Lo ideal es que se guarde en una ruta compartida si es que se planea implementar masivamente después.
Para terminar, clic derecho en la base de datos y seleccionamos Install:
Aceptamos el cuadro de confirmación sobre la instalación:
Comprobando resultados
Si todo sale bien, la corrección debería hacer que la aplicación funcione, por supuesto, si este era el único error:
Si volvemos a monitorear con Process Monitor, la aplicación nunca se dará cuenta de lo sucedido:
Una aplicación puede tener múltiples arreglos para mitigar diferentes problemas; este es uno de los más comunes y como ven, funciona muy bien.
Por supuesto, no es necesario tener el ACT instalado en todas las máquinas donde se quiera implementar, basta con lanzar un script local o remoto que llame al proceso sdbinst.exe con el parámetro –q y el directorio del arreglo para que se instale.
Por ejemplo, si este arreglo lo fuese a instalar en un equipo, y lo tuviese en el directorio C:, ejecutaría:
sdbinst.exe –q C:FileExampleShim.sdb
Claro está, lo ideal, como dije antes, es que el Shim esté en una ruta de red si se quiere hacer una distribución masiva y centralizada.
Conforme mi conocimiento lo permita, documentaré otros arreglos y temas más complejos de ACT aquí en el blog. Empecé por uno de los que consideré puede ser más útil.
Como nota final, el ACT está disponible desde versiones anteriores.
Espero sea de utilidad.
Saludos.
Checho