Как статически идентифицировать системные файлы, от которых зависит приложение?

Как статически идентифицировать системные файлы, от которых зависит приложение?

Чтобы помочь с миграцией приложений из устаревших операционных систем (например, XP), мне нужно определить файлы драйверов (sys), на которые опирается приложение для запуска. Это нужно сделать, проверив существующую систему с установленным приложением, не запуская установщик и само приложение.

Хотя это и не идеальное решение, была предпринята попытка идентифицировать драйверы из коробки (драйверы, добавленные после установки операционной системы), поскольку это сузит количество рассматриваемых файлов sys. API DISM может возвращать статус «Входящие» драйвера, но для этого требуется Windows 7 и выше.

До сих пор надежное решение оказалось неуловимым на XP. Возможно, что запрос метаданных временных меток NTFS (например, Changed) поможет идентифицировать файлы sys, которые были добавлены в файловую систему с момента установки операционной системы. Даже в случае успеха это только сужает область запроса, но фактически не идентифицирует драйверы, от которых зависит приложение.

Я задал похожий вопросздесь.

Итак, как статически идентифицировать системные файлы, от которых зависит приложение?

решение1

Это заблуждение: ни одна программа не "зависит" от .sysфайлов или драйверов. Она зависит только от операционной системы, а операционная система использует любые модули, которые кажутся подходящими.

Например, если ваша программа хочет печатать, она не зависит от драйвера принтера на компьютере, где она была разработана. На другом компьютере, с другой операционной системой или другим принтером будет использоваться другой драйвер.

В другом вашем посте вам посоветовали использовать Зависимый Ходок, который сообщит вам, какие DLL-библиотеки вызывает программа. На целевом компьютере вам нужно будет убедиться, что какая-то версия этих DLL-библиотек доступна.

Некоторые библиотеки DLL, такие как , kernel32.dllявляются неотъемлемой частью Windows и будут существовать в любой версии Windows.

Другие библиотеки DLL, относящиеся, например, к .Net Framework или C/C++ Runtime, могут быть установлены или не установлены на целевом компьютере, и вам также может потребоваться установить нужную версию.

Хотя .Net Framework имеет обратную совместимость, то есть более высокая версия будет работать для программы, скомпилированной с более низкой версией, для среды выполнения C/C++ требуется точная версия, поэтому вам может потребоваться распространять библиотеки DLL вместе с вашим продуктом.

Для этого существует специальный термин:DLL-ад, что вполне уместно. Как разработчику, вам нужно будет тестировать свое распределенное программное обеспечение на как можно большем количестве сред, чтобы минимизировать этот ад. Но будьте уверены, что рано или поздно вы с ним столкнетесь.

Связанный контент