Visual Studio 2005 Runtimes - Part 1: Licht am Ende des Tunnels
So, ich bin seit heute krankgeschrieben bis zum Rest der Woche. Das hält mich aber keineswegs vom Bloggen ab, schließlich tue ich das ja aus dem Bett mit dem Laptop auf dem Schoß und dem Fieberthermometer im Anus. Hoffen wir, daß mir da draus keiner einen Strick dreht...
Zum Problem: Windows XP (Jahrgang 2001) bringt ein äußerst esoterisches Feature mit, die SxS-Execution von DLLs. Jahrelang hat dieses Feature des DLL-Laders ein Mauerblümchendasein gefristet und hat sich allenfalls in Form einer gänzlich neuen comctl32.dll manifestiert, die genau dann geladen wurde, wenn das Binary ein Manifest in Form einer entsprechenden XML-Datei entweder beiligend, oder als Ressource hineinkompiliert hatte. Damit kann man dann den tollen Klickibunti-Luna-Look für sein Binary erzeugen. Und diese comctl32.dll wird, anders als früher, nicht aus dem system32-Verzeichnis geladen,sondern aus diesem komischen winsxs Folder.
Beginnend mit den Runtimes für Visual Studio 2005 (Jahrgang 2005) macht Microsoft aber so richtig ernst mit den Manifesten. So weigert sich etwa ein Binary überhaupt erst, gestartet zu werden, wenn es ohne Manifest erzeugt wurde (zumindest wenn man die Runtime dynamisch linkt). Und wenn man ein Manifest einfügt, hat man erstmal überhaupt keine Kontrolle mehr, von wo die Runtime oder die MFC Dlls geladen werden. Denn wenn erstmal diese Binaries der Runtime über den offiziellen MSI-Installer installiert sind, dann stehen sie im WinSxS-Folder und fortan werden sie immer von dort geladen und nicht mehr vom Installationsverzeichnis. Das Ganze hat eindeutige Vorteile, aber auch handfeste Nachteile:
- Vorteil: Bei einem Bug in der Runtime/MFC können die Binaries auf einen Schlag für alle Applikationen per Windows Update augetauscht werden
- Nachteil: Weiß bei Windows Update Microsoft selbst mal wieder nicht, was es tut, tun auf einen Schlag alle Applikationen nicht mehr
- Nachteil: Eine echte side-by-side execution ist nicht mehr möglich
- Vorteil: Ein Drama wie bei gdiplus.dll, das jeder mit dem JPEG-buffer overrun side-by-side zu seiner Applikation installieren konnte, wird es auch nicht mehr geben.
- Nachteil: Das offizielle Redistributable ist ein MSI Paket und erwartet MSI Version 3.1. Dazu muß man XP SP2 haben oder W2K3Server SP1, oder aber MSI-Redistributables für XP RTM, W2k3Server RTM, XP SP1 oder W2K SP3. In Summe kommt da ein hübscher Brocken an Patches und Service Packs zusammen, um das Ganze auf einem x-beliebigen Rechner zum Fliegen zu bringen.
Der letzte Punkt scheint ein massiver Showstopper für viele ISVs gewesen zu sein. Daher wird allem Anschein nach Visual Studio 2005 SP1 (Jahrgang 2006?) mit einem upgedateten MSI-Installer ausgeliefert, der nur MSI 2.0 voraussetzt. Ich habe den zugehörigen Hotfix von MS Support angefordert und ausprobiert. Es funktioniert ohne Probleme auf Windows XP RTM und Windows 2000 SP4 (müßte auch mit SP3 gehen, habe ich aber keine VMWare dafür).
Das nächste Mal schreibe ich dann, wenn ich nicht gerade im Fieberwahn deliriere, wie man sich kunstvoll um den winsxs-Folder herumbescheißt. Stay tuned!
Trackback address for this post
No feedback yet
Comments are closed for this post.