Registry: WOW6432NODE

**Rakshasa**

Problem: Unter einem 64-Bit-Windows (bspw. XP oder Vista) werden Anfragen von 32-Bit und 64-Bit Programmen unterschiedlich beantwortet:

MSDN

Beispiel:
Unsere (32-Bit) Anwendung möchte auf den Schlüssel "HKEY_LM\Software\Microsoft\Windows" zugreifen (Schreibzugriff).
Tatsächlich aber wird die Anfrage von TRegistry umgeleitet, auf den Schlüssel "HKEY_LM\Software\WOW6432Node\Microsoft\Window s". D.h., der Wert wird in den Schlüssel "HKEY_LM\Software\WOW6432Node\Microsoft\Window s" geschrieben, statt in "KEY_LM\Software\Microsoft\Windows ".

Lösung:
Die TRegistry muss mit speziellen Zugriffsrechten geöffnet werden, um 32-Bit-Anwendungen expliziten Zugriff auf einen der beiden Schlüssel zu geben (also 32-Bit: "HKEY_LM\Software\WOW6432Node\..." oder 64-Bit: "HKEY_LM\Software\...").
Wichtig: Meine Lösungen gehen davon, dass das Programm über Abwärtskompatibilität verfügen soll, d.h. je nachdem, ob ein 64-Bit oder 32-Bit Windows entdeckt wurde, wird anders verfahren.
Um herauszufinden, ob Windows 64-Bit installiert wurde, kann folgende Funktion (von

hier) verwendet werden:

zusammenfalten · markieren

Delphi-Quellcode:

			function IsWow64: Boolean;

type

  TIsWow64Process = function( // Type of IsWow64Process API fn

    Handle: Windows.THandle; var Res: Windows.BOOL

  ): Windows.BOOL; stdcall;

var

  IsWow64Result: Windows.BOOL;      // Result from IsWow64Process

  IsWow64Process: TIsWow64Process;  // IsWow64Process fn reference

begin

  // Try to load required function from kernel32

  IsWow64Process := Windows.GetProcAddress(

    Windows.GetModuleHandle('kernel32'), 'IsWow64Process'

  );

  if Assigned(IsWow64Process) then

  begin

    // Function is implemented: call it

    if not IsWow64Process(

      Windows.GetCurrentProcess, IsWow64Result

    ) then

      raise SysUtils.Exception.Create('IsWow64: bad process handle');

    // Return result of function

    Result := IsWow64Result;

  end

  else

    // Function not implemented: can't be running on Wow64

    Result := False;

end;

So, um jetzt ordentlich zugreifen zu können, müssen zwei neue Typen deklariert werden (

MSDN):

markieren

Delphi-Quellcode:

			 const

 KEY_WOW64_64KEY = $0100;

 KEY_WOW64_32KEY = $0200;

Beispielcode für den LESE-Zugriff (32-Bit-Anwendung) auf einen Unterschlüssel von "HK_LM\Software\...":

zusammenfalten · markieren

Delphi-Quellcode:

			var

  s1,s2: String;

begin

  // Auf Schlüssel "HKEY_LM\Software\WOW6432Node\Microsoft\Windows" zugreifen (umgeleitet!)

  with TRegistry.Create do

  begin

    try

      RootKey := HKEY_LOCAL_MACHINE;

      if OpenKey('\Software\Microsoft\Windows', false) then

      begin

        s1 := ReadString('');

        CloseKey;

      end;

    finally

      free;

    end;

  end;

  // Und jetzt auf den Schlüssel "HKEY_LM\Software\Microsoft\Windows" zugreifen

  with TRegistry.Create(KEY_ALL_ACCESS OR KEY_WOW64_64KEY) do

  begin

    try

      RootKey := HKEY_LOCAL_MACHINE;

      if OpenKey('\Software\Microsoft\Windows', false) then

      begin

        s2 := ReadString('');

        CloseKey;

      end;

    finally

      free;

    end;

  end;

  Showmessage(s1 + #13 + s2);

end;

Der Schreibzugriff ist jetzt ein wenig aufwendiger, ich habe mir dazu eine kleine Function gebaut, die immer - je nach Bedarf - in den einen oder anderen Schlüssel schreibt. Läuft die Anwendung auf einem 32-Bit-Windows, wird der Standard-AccessMode zurückgegeben.
Dabei wird wird an die Function der zu schreibende Schlüsselname gegeben, also bspw. "HKEY_LM\Software\WOW6432Node\Microsoft\Window s" oder "HKEY_LM\Software\Microsoft\Windows". Der Witz ist jetzt, dass durch die Function tatsächlich auch in den angegebenen Schlüssel geschrieben wird, es erfolgt keine "Umleitung".

Achtung: Beispiel verwendet Smartpos() der Unit

FastStrings, da SmartPos() nicht case-sensitive ist. Das Beispiel kann natürlich auch mit Pos() benutzt werden.

zusammenfalten · markieren

Delphi-Quellcode:

			function GetRegAccessMode(sOrtID: String): Cardinal;

begin

  // Bei 32-Bit-Windows kein spezieller Accessmode erforderlich

  if not Is64BitWindows then begin

    Result := KEY_ALL_ACCESS;

    exit;

  end;

  if SmartPos('Wow6432Node', sOrtID, false) > 0 then // 32-Bit-Wert schreiben?

    result := (KEY_ALL_ACCESS OR KEY_WOW64_32KEY)

  else

    result := (KEY_ALL_ACCESS OR KEY_WOW64_64KEY);

  // Alternativ: Mit pos() -> case-sensitive!

  { 

  if Pos('Wow6432Node', sOrtID) > 0 then // 32-Bit-Wert schreiben?

    result := (KEY_ALL_ACCESS OR KEY_WOW64_32KEY)

  else

    result := (KEY_ALL_ACCESS OR KEY_WOW64_64KEY);

  }

end;

Eingebaut wird dass dann in den .Create-Aufruf von TRegistry:

zusammenfalten · markieren

Delphi-Quellcode:

			var

  AccessMode: Cardinal;

  sKey: String;

begin

  sKey := '\Software\Microsoft\Windows';

  AccessMode := GetRegAccessMode(sKey);

  with TRegistry.Create(AccessMode) do

  begin

    try

      {.........}

    finally

      free;

    end;

 end;

Fertig!!

[edit=CalganX]Code-Style und Ressourcenschutz. Mfg, CalganX[/edit]

**Rakshasa**

Zitat von Luckie:

Dann könnte ich den Code eventuell für meinen Usermanager gebrauchen. Muss ich mal gucken.

Also unter Windows 64 braucht diesen (oder ähnlichen) Code jede Anwendung, die auf einen der Schlüssel

HKEY_LOCAL_MACHINE\Software
HKEY_USERS\*\Software\Classes
HKEY_USERS\*_Classes

zugreifen will.

Link

Es gibt allerdings auch Schlüssel, die für alle Anwendungen (32 oder 64 Bit) gleich sind:

MSDN

Zitat:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\HCP
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography \Calais\Current
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography \Calais\Readers
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography \Services
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\SystemSh ared
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\TIP
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCe rtificates
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Non-Driver Signing
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAS
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Software\Mic rosoft\Shared Tools\MSInfo
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertif icates
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TermServLice nsing
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Transaction Server
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontDpi
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontMapper
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Ports
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Control Panel\Cursors\Schemes
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Group Policy
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Policies
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Setup
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Setup\OC Manager
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Telephony\Locations
HKEY_LOCAL_MACHINE\SOFTWARE\Policies

Eine andere Möglichkeit scheint die Verwendung von "RegDisableReflectionKey" und "RegEnableReflectionKey" zu sein (

MSDN). Wie genau das funktionieren soll, weiß ich allerdings auch noch nicht.

Auf jeden Fall wird das Schreiben von Anwendungen ziemlich ätzend auf dieser Ebene, da ständig die 64-Bit Varianten der Schlüssel ebenfalls abgefragt werden müssen.

Registry: WOW6432NODE

Registry: WOW6432NODE

Re: Registry: WOW6432NODE

Forumregeln