Die Registry Umleitung kümmert sich (wie der Name schon vermuten lässt) um die Umleitung von Registry Zugriffen von 32-Bit Applikationen. Dies ist nötig, um die friedliche Koexistenz von 32 und 64-Bit Anwendungen zu garantieren.
Microsoft verwendet hier zweierlei Taktiken: Einige Schlüssel werden in der Registry für 32-Bit Anwendungen umgeleitet, betroffen hiervon sind:
Letzterer ist ein künstlicher Schlüssel, abgeleitet aus HKEY_LOCAL_MACHINE\Software\Classes und HKEY_CURRENT_USER\Software\Classes.
Die zweite Technik die auf die Registry angewandt wird, ist der sog. Registry Reflektor, welcher Einträge aus dem 32-Bit Pfad der Registry in den 64-Bit Pfad kopiert und zurück. Lediglich die drei Schlüssel Run/RunOnce/RunOnceEx werden ausschließlich aus dem 32-Bit Pfad in den 64-Bit Pfad verschoben, nicht jedoch andersherum.
Betroffen vom Reflektor sind:
Wie genau dieser Reflektor funktioniert und was er überhaupt bezwecken soll, demonstriert folgendes Fallbeispiel:
Nach einer frischen Windows XP64 Installation ist die 64-Bit wordpad.exe zuständig für das öffnen von .doc Dateien. Dies gilt sowohl für 32 als auch 64-Bit Anwendungen, die eine .doc Datei öffnen wollen.
Installiert man nun ein 32-Bit Office XP, ändert sich die Zuständigkeit und die 32-Bit winword.exe wird für den .doc Dateien zugewiesen. Der Registry Reflektor kopiert die entsprechenden Werte aus dem 32-Bit Teil der Registry in den 64-Bit Teil, so dass sowohl 32 als auch 64-Bit Anwendungen nun zum öffnen von .doc Dateien die 32-Bit winword.exe benutzen.
Installiert der Benutzer als nächstes ein 64-Bit Office (welches derzeit ohnehin noch nicht existiert), so wird die 64-Bit winword.exe für das Öffnen von .doc Dateien zugewiesen. Der Registry Reflektor kopiert nun die entsprechenden Werte aus dem 64-Bit Pfad der Registry in den 32-Bit Pfad, womit nun sowohl 32 als auch 64-Bit Anwendungen zum öffnen von .doc Dateien die 64-Bit winword.exe verwenden.
Bei Microsoft heißt dies „last writer wins“, oder auch „most recently installed“, sprich was zuletzt installiert wurde, bekommt sowohl für 32 als auch 64-Bit Anwendungen die Zuweisung erteilt. Würde im obigen Beispiel also die Reihenfolge der Office Installation umgekehrt abgelaufen sein, so wäre am Ende die 32-Bit winword.exe zuständig gewesen.
Dateisystem Umleitung
Die Umleitung des Dateisystems ist nötig, da das SYSTEM32 Verzeichnis aus Kompatibilitätsgründen für 64-Bit Anwendungen reserviert ist. Grund für diese etwas sinnlos erscheinende Konvention ist ein Zugeständnis Microsofts an die Programmierer dieser Welt – hierdurch wird das Umschreiben von 32-Bit Anwendungen auf 64-Bit erheblich erleichtert.
Da weiterhin sowohl 32 als auch 64-Bit DLLs identische Namen tragen, wurde ein separates Verzeichnis für 32-Bit Anwendungen nötig: %systemroot%\SysWOW64. Jedes Mal, wenn eine 32-Bit Applikation Zugriffe auf %systemroot%\System32 durchführt, werden diese automatisch nach %systemroot%\SysWOW64 umgeleitet. Ausnahmen sind unter anderem der Druckspooler, um Interoperabilität zwischen 32 und 64-Bit Anwendungen beim Drucken zu garantieren.
Eine etwas andere Taktik wird für Variablen wie %ProgramFiles% angewandt, welche über eine Abfrage per SHGetSpecialFolderPath oder eine Registry Abfrage umgeleitet werden. Beides würde bei 64-Bit Anwendungen wie bisher bei 32-Bit Windows üblich „C:\Programme“ zurückliefern, bei 32-Bit Anwendungen hingegen „C:\Programme(x86)“. Um trotzdem auch 32-Bit Anwendungen die Verwendung von %ProgramFiles% zu ermöglichen, wird dies von WoW64 abgefangen und auf %ProgramFiles(x86)% umgeleitet. Diese Variable ist für sämtliche Anwendungen (ergo auch 64-Bit) deklariert und zeigt nach „C:\Programme(x86)“. Da dies jedoch oftmals bei Installern hart kodiert ist (Engl. „hard coded“, bedeutet, dass der Name des Verzeichnisses, der ja Sprachabhängig ist, nicht über Variablen abgefragt, sondern fest einprogrammiert wird), wird hier vom Anwender Handarbeit verlangt.
Memory Management
Ein weiteres Problem, das es zu lösen galt, ergibt sich bei der Speicherverwaltung, genau gesagt bei der Größe der Speicherseiten (pages). 32-Bit Systeme verwenden 4k pages, wohingegen bei 64-Bit Systeme 8k pages üblich sind. WoW64 simuliert hier besagte 4k pages in den niederwertigen 8k, so dass 32-Bit Anwendungen hiervon nichts merken.
32-Bit Anwendungen sind jedoch weiterhin von der 2GB Speichergrenze pro Prozess betroffen, der Trick mit 3GB Speicherzuweisung per /LARGEADDRESSAWARE:YES funktioniert hier nicht. Dies gilt logischerweise auch für 64-Bit Programme, die einer 32-Bit Anwendung Speicher zuweisen müssen. Microsoft hat hier für interne Präsentationen ein kleines Tool geschrieben, welches Speicher belegt und die aktuelle Belegung für den Prozess anzeigt. Bei der Microsoft Route64 Tour konnten sich die Besucher selbst davon überzeugen, dass beim 32-Bit Prozess nach 2GB Schluss war, wohingegen der 64-Bit Prozess erst bei weit höheren Werten (installierter Speicher + Auslagerungsdatei) die Segel streicht.
Diesen Artikel bookmarken oder senden an ...