Para ayudar con la migración de aplicaciones fuera de sistemas operativos heredados (por ejemplo, XP), necesito identificar los archivos del controlador (sys) en los que depende una aplicación para poder ejecutarse. Esto debe hacerse inspeccionando un sistema existente con la aplicación instalada, sin ejecutar el instalador y sin ejecutar la aplicación.
Aunque no es una solución perfecta, se ha intentado identificar los controladores listos para usar (controladores agregados desde la instalación del sistema operativo), ya que esto reducirá la cantidad de archivos sys a considerar. La API DISM puede devolver el estado de la bandeja de entrada de un controlador, pero esto requiere Windows 7 y superior.
Hasta ahora, una solución fiable ha resultado evasiva en XP. Es posible que la consulta de los metadatos de la marca de tiempo NTFS (por ejemplo, Cambiados) ayude a identificar los archivos sys que se han agregado al sistema de archivos desde que se instaló el sistema operativo. Incluso si tiene éxito, esto sólo reduce el campo de investigación, en realidad no identifica los factores de los que depende una aplicación.
He hecho una pregunta similaraquí.
Entonces, ¿cómo identificar estáticamente los archivos sys de los que depende una aplicación?
Respuesta1
Esta es una idea errónea: ningún programa es "dependiente" de .sysarchivos o controladores. Sólo depende del sistema operativo, y el sistema operativo utiliza cualquier módulo que parezca apropiado.
Por ejemplo, si su programa quiere imprimir, no depende del controlador de impresora de la computadora donde fue desarrollado. En otro ordenador, con otro sistema operativo u otra impresora, se utilizará otro controlador.
En su otra publicación, le aconsejaron que utilizara el Caminante de dependencia, que le indicará qué DLL llama un programa. En la computadora de destino, deberá asegurarse de que haya alguna versión de estas DLL disponible.
Algunas DLL, como las que kernel32.dllson parte integral de Windows y existirán en cualquier versión de Windows.
Otras DLL, pertenecientes por ejemplo a .Net Framework o C/C++ Runtime, pueden o no estar instaladas en la computadora de destino, y es posible que también necesite instalar la versión correcta.
Si bien .Net Framework es compatible con versiones anteriores, lo que significa que una versión superior funcionará para un programa compilado con una versión inferior, C/C++ Runtime necesita la versión exacta, por lo que es posible que deba distribuir las DLL con su producto.
Hay un término creado para esto:DLL infierno, lo cual es totalmente apropiado. Como desarrollador, necesitarás probar tu software distribuido en tantos entornos como sea posible para minimizar este infierno. Pero ten por seguro que tarde o temprano lo encontrarás.