Code does not handle keys otherwise mapped to Wow6432Node in 32-bit builds about winreg HOT 3 CLOSED

Okay first of all, Wow6432 is the subsystem for running 32-bit apps on 64-bit Windows installations. It does not exist on actual 32-bit Windows.

So as far as I understood this ticket, attempting to run a 32-bit application ON 64-BIT WINDOWS would write to the Wow6432Node sub-key (within the actually desired key; we can see them in places such as HKEY_CURRENT_USER/Software/Wow6432Node/).

Well, it is now 2019 and I am testing an x86 (32-bit) build on the latest Windows 10 64-bit, and it writes to the 64-bit registry view even though it is a 32-bit application, so I guess Microsoft changed the behavior to make even 32-bit apps write to the 64-bit keys by default.

But, yeah, if older Windows versions write in Wow6432Node if you run a 32-bit app on 64-bit Windows, then it makes sense to include the KEY_WOW64_64KEY flag "just in case".

According to MSDN https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-key-security-and-access-rights it says:

KEY_WOW64_64KEY (0x0100)
Indicates that an application on 64-bit Windows should operate on the 64-bit registry view. This flag is ignored by 32-bit Windows. For more information, see Accessing an Alternate Registry View.
This flag must be combined using the OR operator with the other flags in this table that either query or access registry values.
Windows 2000: This flag is not supported."

There is also the opposite force-flag:

KEY_WOW64_32KEY (0x0200)
Indicates that an application on 64-bit Windows should operate on the 32-bit registry view. This flag is ignored by 32-bit Windows. For more information, see Accessing an Alternate Registry View.
This flag must be combined using the OR operator with the other flags in this table that either query or access registry values.
Windows 2000: This flag is not supported.

So I did some more testing:

Windows 10 totally ignores both flags, and ALWAYS uses the 64-bit registry even if you use "KEY_WOW64_32KEY" to try to force it to open the 32-bit node.

Either way, whatever caused @jbmonroe to write the original ticket seems to only be an issue on older Windows versions, but to be safe I will take your advice and include the KEY_WOW64_64KEY flag in my key access parameter, since that says that 32-bit apps on 64-bit Windows will use the 64-bit key. So IF there is some OS where this is an actual issue, the users should be able to launch either 32-bit or 64-bit versions interchangeably and still have the same app settings!

Would be good if @jbmonroe could clarify what the original issue was.

from winreg.

Methods like RegKey::Create and RegKey::Open take a REGSAM desiredAccess parameter, that you can use to customize and fine-tune the desired access, including the KEY_WOW64_64KEY flag you mentioned (a list of these flags can be found in the "Registry Key Security and Access Rights" MSDN page). There's a RegKey constructor overload taking this REGSAM desiredAccess parameter, as well.

I don't feel I want to force to every users of this library a value different than the default here (which, according to this clarifying StackOverflow answer, is: "Leaving the flag out (the default) on a 64-bit OS will send registry accesses from 32-bit processes to the 32 bit registry view, and accesses from 64-bit processes to the 64 bit registry view."). Different users may need different settings, so I prefer matching this library default to the underlying native Windows API default, and let users specify their desired flags in their own code.

from winreg.

I'm still not convinced that automatically adding this KEY_WOW64_64KEY flag "under the hood" in the library's code would be a good idea. What if some users of this library don't want this flag? Why should I force it in the library's code? Moreover, according to @VideoPlayerCode's comment, the behavior of this flag doesn't even seem consistent. So, I prefer leaving the free optional addition of this flag to user's code.

from winreg.