On 12/18/2014 06:21 PM, Akihiro Sagawa wrote:
dlls/advapi32/registry.c | 99 ++++++++++++++++++++++++++++++++++++------ dlls/advapi32/tests/registry.c | 6 +-- 2 files changed, 88 insertions(+), 17 deletions(-)
Just curious, why HKLM\Software needs special handling in this case? In other words is there a solution that covers all paths?
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
-
Akihiro Sagawa -
Nikolay Sivov