为了帮助将应用程序从旧操作系统（例如 XP）迁移出来，我需要识别应用程序运行时所依赖的驱动程序 (sys) 文件。这需要通过检查安装了应用程序的现有系统来完成，无需运行安装程序，也无需运行应用程序。
虽然这不是一个完美的解决方案，但已尝试识别开箱即用的驱动程序（自安装操作系统以来添加的驱动程序），因为这将缩小要考虑的系统文件的数量。DISM API 可以返回驱动程序的收件箱状态，但这需要 Windows 7 及更高版本。
到目前为止，可靠的解决方案在 XP 上被证明是回避性的。查询 NTFS 时间戳元数据（例如，已更改）可能有助于识别自安装操作系统以来已添加到文件系统中的系统文件。即使成功，这也只会缩小查询范围，而实际上并不能识别应用程序所依赖的驱动程序。
我问过类似的问题这里。
那么，如何静态识别应用程序所依赖的sys文件呢？
答案1
这是一个误解：没有程序“依赖”.sys文件或驱动程序。它只依赖于操作系统，操作系统会使用任何合适的模块。
例如，如果你的程序要打印，它不依赖于开发它的计算机上的打印机驱动程序。在另一台计算机上，使用另一个操作系统或另一台打印机，将使用另一个驱动程序。
在你的另一篇文章中，你被建议使用 依赖性遍历器，它将告诉您程序调用了哪些 DLL。在目标计算机上，您需要确保这些 DLL 的某个版本可用。
某些 DLLkernel32.dll是 Windows 不可或缺的一部分，并且会存在于任何 Windows 版本中。
其他 DLL（例如与 .Net Framework 或 C/C++ 运行时有关的 DLL）可能已安装或尚未安装在目标计算机上，您可能还需要安装正确的版本。
虽然 .Net Framework 向后兼容，这意味着较高版本可以适用于使用较低版本编译的程序，但 C/C++ 运行时需要精确的版本，因此您可能需要随产品分发 DLL。
为此，有一个术语被创建：DLL地狱，这完全是合理的。作为一名开发人员，你需要在尽可能多的环境中测试你的分布式软件，以尽量减少这种地狱。但请放心，你迟早会遇到它。