3

我正在处理的代码有 32 位和 64 位组件，它们需要在注册表中共享信息。因此，我试图在使用该NtOpenKey函数（用户模式等效于ZwOpenKey）时控制注册表重定向 - 我需要从 64 位代码调用此函数但访问 32 位注册表。（以前的代码只有 32 位，现在它正在升级到 64 位，所以我更喜欢尽可能多地使用现有代码——也就是说，我不想重写所有要使用的代码RegOpenKeyEx。）

自然地，NtOpenKey它不识别KEY_WOW64_32KEY访问标志，这与高级注册表函数不同，因此无法指定重定向。

在这一点上，我能想到的唯一解决方案是Wow6432Node在访问注册表时显式地硬编码键名；就像是：

\Registry\Machine\Software\Wow6432Node\MyCompanyKey\MyKey

不幸的是，这更像是一种黑客行为，微软特别不鼓励这样做。

这个问题有正确的解决方案吗？通读文档没有帮助，我也找不到任何相关的搜索结果。

编辑：只是一点额外的细节：我需要支持 Windows Server 2003 32 位/64 位、Windows 7/8 和 Windows Server 2008 32 位/64 位。（基本上所有从 Windows Server 2003 + Windows 7 及更高版本开始的服务器版本。）

4

2 回答 2

2

本机 API 不提供与KEY_WOW64_32KEY. 您的选择是：

  1. 使用 Win32 API。
  2. 坚持使用本机 API 并对路径进行硬编码。
  3. 混合使用 Win32 和本机 API。HKLM\Software使用Win32 API 打开KEY_WOW64_32KEY. 然后调用NtQueryKey以找出密钥的本机名称。然后从那里使用本机 API。这可以解决您对硬编码的反对意见。

选项 3 听起来很合理，但我从来没有打电话NtQueryKey，甚至不能确定这个想法是否有效。

于 2012-11-05T22:31:41.680 回答
0

显然我误解了你的问题——我认为这个标志是一个关键选项，而不是一个访问说明符。
在这种情况下，我相信作为访问掩码NtOpenKey应该可以正常工作。KEY_WOW64_32KEY当你尝试时会发生什么？

旧答案（错误）：

这就是为什么 Windows Vista & 后来推出NtOpenKeyEx.

我建议NtOpenKeyEx在可用时使用（确保动态链接，而不是静态链接），如果不可用，NtCreateKey则尽可能使用，或以Wow6432Node其他方式使用。

没有其他解决方案AFAIK。

于 2012-11-05T19:36:23.520 回答