The code I'm working on has both 32-bit and 64-bit components and they need to share information in the registry. Because of this, I'm trying to control registry redirection when using the NtOpenKey
function (the user-mode equivalent of ZwOpenKey
) - I need to call this function from 64-bit code but access the 32-bit registry. (The code used to be 32-bit only and now it's getting upgraded to 64-bit so I'd prefer using as much of the existing code as possible - this is to say I'd prefer not to rewrite everything to use RegOpenKeyEx
.)
Naturally, NtOpenKey
doesn't recognize the KEY_WOW64_32KEY
access flag, unlike high-level registry functions so there's no way to specify redirection.
At this point the only solution I can think of is to explicitly hardcode Wow6432Node
in the key names when accessing the registry; something like:
\Registry\Machine\Software\Wow6432Node\MyCompanyKey\MyKey
Unfortunately, this is more of a hack and it's specifically discouraged by Microsoft.
Is there a correct solution to this problem? Reading through the documentation didn't help and I couldn't find any relevant search results either.
Edit: just a bit of extra detail: I need to support Windows Server 2003 32-bit/64-bit, Windows 7/8 and Windows Server 2008 32-bit/64-bit. (Basically all server flavors starting with Windows Server 2003 + Windows 7 and over.)
The native API does not offer an equivalent to KEY_WOW64_32KEY
. Your options are:
HKLM\Software
with KEY_WOW64_32KEY
. Then call NtQueryKey
to find out the native name of the key. And then use the native API from there on. This gets around your objection to hard coding.Option 3 sounds plausible, but I've never called NtQueryKey
and can't even be sure that the idea works.