[3/3] advapi32: Fix HKLM\Software handling when opening with KEY_WOW64_32KEY.

[Akihiro Sagawa]

On Thu, 18 Dec 2014 22:58:38 +0300, Nikolay Sivov wrote:
> Just curious, why HKLM\Software needs special handling in this case?
> In other words is there a solution that covers all paths?

Good question. From my point of view, the second answer is no. Because
Wow6432Node handling is different from HKLM\Software and HKCR though
they have the same name.

Opening keys after opening HKLM\Software with KEY_WOW64_32KEY, the
subsequent key is looked up in Wow6432Node subkey on Windows 7. My
previous patch (commit 88778ec) shows this. If my assumption is false,
we get 64-bit view values in the tests. In other words, my test shows
Wow6432Node key is automatically opened after opening HKLM\Software with
KEY_WOW64_32KEY.

On the other hand, opening keys after opening HKCR with KEY_WOW64_32KEY,
an ordinary extension name key is looked up in HKCR (and not
HKCR\Wow6432Node). Just a few special keys[1] are redirected into
HKCR\Wow6432Node. Supposing that opening HKCR with KEY_WOW64_32KEY
automatically opens Wow6432Node subkey like HKLM\Software, we can't look
up ordinary extension name by the key handle due to the absence of
keys under HKCR\Wow6432Node. Therefore opening HKCR with KEY_WOW64_32KEY
doesn't open Wow6432node implicitly, this behavior doesn't match
HKLM\Software's strategy.

To wrap up, we need a different approach to implement Wow6432Node
handling for HKLM\Software and HKCR.

[1] ... CLSID, DirectShow, Interface, Media Type, MediaFoundation keys.

Regards,
Akihiro Sagawa