如何靜態識別應用程式所依賴的sys檔案？

Question

為了幫助將應用程式從舊版作業系統（例如 XP）遷移出來，我需要識別應用程式運行所依賴的驅動程式 (sys) 檔案。這需要透過檢查安裝了應用程式的現有系統來完成，而不運行安裝程序，也不運行應用程式。

雖然不是完美的解決方案，但已嘗試識別現成的驅動程式（自安裝作業系統以來新增的驅動程式），因為這將縮小要考慮的 sys 檔案的數量。 DISM API 可以傳回驅動程式的收件匣狀態，但這需要 Windows 7 及更高版本。

到目前為止，可靠的解決方案已被證明在 XP 上是迴避的。查詢 NTFS 時間戳記資料（例如變更）可能有助於識別自安裝作業系統以來已新增至檔案系統的 sys 檔案。即使成功，這也只會縮小查詢範圍，而實際上並不能識別應用程式所依賴的驅動程式。

我問過類似的問題這裡。

那麼，如何靜態識別應用程式所依賴的sys檔案呢？

Answer 1

這是一個誤解：沒有程式「依賴」.sys檔案或驅動程式。它僅依賴作業系統，並且作業系統使用任何看起來合適的模組。

例如，如果您的程式想要列印，它並不依賴於開發它的電腦上的印表機驅動程式。在另一台具有不同作業系統或另一台印表機的電腦上，將使用另一個驅動程式。

在您的其他貼文中，建議您使用 依賴步行者，它會告訴您程式呼叫了哪些 DLL。在目標電腦上，您需要確保這些 DLL 的某些版本可用。

某些 DLL，如kernel32.dllWindows 的組成部分，將存在於任何 Windows 版本上。

其他 DLL（例如與 .Net Framework 或 C/C++ Runtime 相關的）可能會也可能不會安裝在目標電腦上，而且您可能還需要安裝正確的版本。

雖然 .Net Framework 向後相容，這意味著較高版本適用於使用較低版本編譯的程序，但 C/C++ 運行時需要確切的版本，因此您可能需要隨產品分發 DLL。

為此創建了一個術語：DLL地獄，這是完全合適的。作為開發人員，您需要在盡可能多的環境中測試分散式軟體，以盡量減少這種情況。但請放心，遲早你會遇到它。