Um bei der Migration von Anwendungen von älteren Betriebssystemen (z. B. XP) zu helfen, muss ich Treiberdateien (sys) identifizieren, auf die eine Anwendung angewiesen ist, um ausgeführt zu werden. Dies muss durch die Überprüfung eines vorhandenen Systems mit der installierten Anwendung erfolgen, ohne das Installationsprogramm auszuführen und ohne die Anwendung auszuführen.
Obwohl dies keine perfekte Lösung ist, wurde versucht, Out-of-Box-Treiber (Treiber, die seit der Installation des Betriebssystems hinzugefügt wurden) zu identifizieren, da dies die Anzahl der zu berücksichtigenden Systemdateien einschränkt. Die DISM-API kann den Posteingangsstatus eines Treibers zurückgeben, dies erfordert jedoch Windows 7 und höher.
Bisher hat sich eine zuverlässige Lösung unter XP als schwer lösbar erwiesen. Es ist möglich, dass die Abfrage von NTFS-Zeitstempel-Metadaten (z. B. „Geändert“) dabei hilft, Sys-Dateien zu identifizieren, die dem Dateisystem seit der Installation des Betriebssystems hinzugefügt wurden. Selbst wenn dies erfolgreich ist, schränkt dies nur den Untersuchungsbereich ein und identifiziert nicht wirklich Treiber, von denen eine Anwendung abhängt.
Ich habe eine ähnliche Frage gestelltHier.
Wie kann man also statisch Sys-Dateien identifizieren, von denen eine Anwendung abhängt?
Antwort1
Das ist ein Irrtum: Kein Programm ist von .sysDateien oder Treibern „abhängig“. Es ist nur vom Betriebssystem abhängig, und das Betriebssystem verwendet die Module, die ihm geeignet erscheinen.
Wenn Ihr Programm beispielsweise drucken möchte, ist es nicht auf den Druckertreiber auf dem Computer angewiesen, auf dem es entwickelt wurde. Auf einem anderen Computer, mit einem anderen Betriebssystem oder einem anderen Drucker wird ein anderer Treiber verwendet.
In Ihrem anderen Beitrag wurde Ihnen geraten, die Abhängigkeits-Walker, das Ihnen sagt, welche DLLs ein Programm aufruft. Auf dem Zielcomputer müssen Sie sicherstellen, dass eine Version dieser DLLs verfügbar ist.
Einige DLLs, wie beispielsweise, kernel32.dllsind ein integraler Bestandteil von Windows und sind in jeder Windows-Version vorhanden.
Andere DLLs, die sich beispielsweise auf das .Net Framework oder die C/C++-Runtime beziehen, sind möglicherweise auf dem Zielcomputer installiert oder nicht und Sie benötigen möglicherweise auch die richtige Version.
Während .Net Framework abwärtskompatibel ist, was bedeutet, dass eine höhere Version für ein mit einer niedrigeren Version kompiliertes Programm funktioniert, benötigt die C/C++-Runtime die exakte Version, sodass Sie die DLLs möglicherweise mit Ihrem Produkt verteilen müssen.
Dafür gibt es einen Begriff:DLL-Hölle, was völlig angemessen ist. Als Entwickler müssen Sie Ihre verteilte Software in so vielen Umgebungen wie möglich testen, um diese Hölle zu minimieren. Aber seien Sie versichert, dass Sie früher oder später darauf stoßen werden.