Windows-Anwendung richtig archivieren

[Krishty]

Ihr wisst vielleicht, dass ich gern Dinge archiviere. Auch Programme.

Aber was tun, wenn die Programme auf einem uralt-DirectX-SDK aufbauen oder auf einer MFC-Version von 2008? Wenn sich die Setups dafür kaum noch finden lassen oder auf eurem modernen System schlicht nicht mehr laufen? Ihr wollt ein altes Projekt von 2005 starten, aber es geht nicht, weil irgendeine Komponente fehlt? Ihr wollt Spiele ohne Installation spielen können?


d3dx9_42.dll nicht gefunden

Das ist der einfachste Fall, zum Aufwärmen.

Erstmal brauchen wir die DLL. Zieht euch die DirectX End-User Runtimes (June 2010) so lange es sie noch gibt.

Dann öffnet das Setup in 7-Zip. (Rechtsklick -> als Archiv öffnen.) Ihr seht eine Liste von Dateinamen. Sucht nach irgendwas mit _42 drin.

Bingo: Aug2009_d3dx9_42_x86.cab (oder _x64, falls die Anwendung 64-bitting ist).

Öffnet dieses CAB erneut in 7-Zip. Dann extrahiert die d3dx9_42.dll daraus ins Verzeichnis der EXE, die danach sucht.

Und dann speichert die Kollektion von D3D-CABs gut weg, falls ihr sie für später nochmal braucht.
Fertig.


The program can't start because MSVCP100.dll is missing from your computer.Try reinstalling the program to fix this problem.

Auch das ist recht einfach – msvcrXXX.dll, msvcpXXX.dll, und mfcXXX.dll sind die Laufzeitbibliotheken für Visual C, Visual C++, und MFC. Das XXX entspricht einer bestimmten Visual Studio-Version:

• 90: Visual C++ 2008
• 100: Visual C++ 2010
• 110: Visual C++ 2012
• 120: Visual C++ 2013
• 130: Visual C++ 2015
• 140: Visual C++ 2017

Googelt dann nach Visual C++ 20XX Redistributable x86 (oder x64, falls euer Programm 64-bittig ist). Das sollte euch zu einem Download führen.

Herunterladen, in 7-Zip öffnen. Durch den Installer gucken. Irgendwo muss eine Datei ähnlichen Namens liegen.

Extrahiert sie, platziert sie neben der EXE, entfernt den Namensschmuck drumherum. Tipp: Falls das Programm die msvcp-Version braucht, braucht es immer auch die msvcr-Version.

Fertig.


This application has failed to start because the side-by-side configuration is incorrect. Reinstalling the application may fix this problem.

Dieser Fehler ist der Bastard unter den Abhängigkeitsproblemen. Die Anwendung hat in diesem Fall eine Abhängigkeit mit bestimmter Versionsnummer ins Manifest eingetragen. Da kommt man nicht einfach drum herum.

Erstmal geht ihr in die Ereignisanzeige / Event Viewer von Windows. (Wer nicht weiß, wie – Internet hilft.)

Dort findet ihr unter „Application“ einen Fehler ganz oben. Der lautet dann etwa so:

Activation context generation failed for "X:\xxx.exe". Dependent Assembly Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

Mit dem Wissen von oben führt uns der Text schonmal weiter: Die Visual C++-Runtime fehlt wieder. Version 90, also 2008.

Googeln nach Visual C++ 2008 Redistributable (x86 oder x64 nicht vergessen!). Es gibt verschiedene Versionen: 2008. 2008 SP1. 2008 SP1 mit Security Update.

Wenn ihr alle runterladet und die Dateinamen in den vc_red.cabs vergleicht, seht ihr, dass eine davon msvcp90.dll.21022.08.Microsoft_VC90_CRT_x64.RTM heißt. Extrahiert sie (und ihren msvcr-Kameraden).

Die Dateien liegen nun zwar im Verzeichnis, aber Windows lädt sie noch immer nicht von dort: Da die Anwendung stur auf dem Side-by-Side-System aufbaut, müssen die DLLs dort eingetragen sein. Tricks wie dot.local unter Windows XP (ein Verzeichnis foo.exe.local anlegen, das den Loader informiert, die Komponenten lokal zu laden statt aus dem globalen SxS-Cache) funktionieren seit Vista nicht mehr. Um das aufzulösen, muss das Manifest her. Auch das liegt im CAB: manifest.21022.08.Microsoft_VC90_X64.RTM. Extrahiert es und benennt es um zu Microsoft.VC90.CRT.MANIFEST.

Woher ich das weiß? Weil ich wirklich mal, wie in der Fehlermeldung beschrieben, sxstrace auf der Konsole gestartet habe:

sxstrace Trace -logfile:"C:\Users\Krishty\Desktop\sxstrace.bin"

Dann habe ich die Anwendung gestartet, die Fehlermeldung weggeklickt, und das Tracing in der Konsole via RETURN beendet. Danach konnte ich die Trace-Datei via

sxstrace Parse -logfile:"C:\Users\Krishty\Desktop\sxstrace.bin" -outFile:"C:\Users\Krishty\Desktop\sxs.log"

in Text umwandeln. Darin stand:

INFO: Resolving reference Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
INFO: Resolving reference for ProcessorArchitecture amd64.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_64\Microsoft.VC90.CRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.CRT.DLL.
INFO: Attempt to probe manifest at X:\Microsoft.VC90.CRT.DLL.
INFO: Attempt to probe manifest at X:\Microsoft.VC90.CRT.MANIFEST.
INFO: Attempt to probe manifest at X:\Microsoft.VC90.CRT\Microsoft.VC90.CRT.DLL.
INFO: Attempt to probe manifest at X:\Microsoft.VC90.CRT\Microsoft.VC90.CRT.MANIFEST.
INFO: Attempt to probe manifest at X:\xxx.exe.local\Microsoft.VC90.CRT.DLL.
INFO: Attempt to probe manifest at X:\xxx.exe.local\Microsoft.VC90.CRT.MANIFEST.
INFO: Attempt to probe manifest at X:\xxx.exe.local\Microsoft.VC90.CRT\Microsoft.VC90.CRT.DLL.
INFO: Attempt to probe manifest at X:\Microsoft.VC90.CRT\Microsoft.VC90.CRT.MANIFEST.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
ERROR: Cannot resolve reference Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
ERROR: Activation Context generation failed.

… jetzt wissen wir, an welchen Orten Windows nach dem Manifest und den DLLs sucht – und das könnt ihr für alle fehlenden Komponenten wiederholen.


Ich wollte gern noch konkrete Beispiele posten, z.B. für das uralte Far Cry, das man so als portable Installation nutzen kann. Ein anderes Mal.

[mrz]

auf eurem modernen System schlicht nicht mehr laufen?

Dann nutze ich eine VM. Habe hier immer ein Win98, WinXP und Win7 Template griffbereit.

Kurz klonen und dann kann man rumsauen wie man will, auch Dank Snapshots.

Und zum "archivieren" speichert man einfach die ganze VM. Am praktischsten als OVA.

[Krishty]

Das mit den Snapshots ist natürlich ein riesen Vorteil.

Meine Erfahrung mit VMs war aber bisher sehr nüchtern: Zähes Multi-Threading, keine Grafikbeschleunigung, und teils starke Abhängigkeit von der Host-Architektur (eine unter AMD angelegte VM spielt nicht auf Intel-Architektur, weil Windows sich mit 3DNow!-Unterstützung installiert hat, die es auf Intel natürlich nicht mehr gibt.) Aber in den letzten Jahren dürfte sich auch da viel getan haben …

[mrz]

>> Das mit den Snapshots ist natürlich ein riesen Vorteil.

Dann such mal nach "vm record replay" ;-)

>> Zähes Multi-Threading

Liegt oft an falscher Konfiguration. Viele neigen dazu der VM zuviele Cores zu geben.
Btw konnte ich viele, extrem mühsame und schwer reproduzierbare Multithreadingbugs erst dank VMs analysieren.

>> keine Grafikbeschleunigung

Gibt es mittlerweile.

>> teils starke Abhängigkeit von der Host-Architektur

Grundsätzlich ist das schon ein Problem, ich kann aber nicht beurteilen wie gross es ist.
Bewege mich in den letzten Jahren nur in der Intel/VMware Welt, und bei VMware
gibt es betreffend der CPU Architektur ein sogenannten EVC Mode welcher man setzen kann.
Kam damit aber nur in Kontakt wenn eine VM im Livebetrieb auf einen anderen Host migriert werden musste,
oder wenn die VM suspended war (klar, Inhalt vom Guestmemory ist CPU spezifisch).
Technisch sehe ich kein Hinderniss dass der Hypervisor einfach CPU spezifischen Instruktionen emuliert.

[Schrompf]

Zum Rest kann ich nix beitragen, aber das hier:

>> keine Grafikbeschleunigung

Gibt es mittlerweile.

Ist zwar auf dem Papier vorhanden, aber mehr oder minder unbenutzbar. Zumindest in nem Linux Guest, der ja auch noch jede Menge hausgemachter Probleme mit Treibern, Window Managern und ähnlichem hat. OpenGL-Calls gehen einfach stillschweigend schief oder kehren gar nicht mehr zurück. Ein Trauerspiel.

[mrz]

Zum Rest kann ich nix beitragen, aber das hier:

>> keine Grafikbeschleunigung

Gibt es mittlerweile.

Ist zwar auf dem Papier vorhanden, aber mehr oder minder unbenutzbar. Zumindest in nem Linux Guest, der ja auch noch jede Menge hausgemachter Probleme mit Treibern, Window Managern und ähnlichem hat. OpenGL-Calls gehen einfach stillschweigend schief oder kehren gar nicht mehr zurück. Ein Trauerspiel.

Welcher Hypervisor? Alleine schon wegen macOS Testing verwenden wir ausschliesslich VMware (ESXi). Ich weiss nicht wie es heute genau um KVM steht, vor paar Jahren war er unbrauchbar und auch noch heutzutage sagen wir unseren Kunden, dass wenn sie mit skurrilen Problemen durchs Environment zu uns kommen, und wir dann sehen dass unser Zeug in einem Guest unter KVM läuft, sie das erstmal auf eine physikalische Maschine auslagern müssen weil wir mit dem KVM Thema durch sind und hier kein KVM Support mehr machen.