Windows 64 位注册表与 32 位注册表
我听说在 Windows x64 架构上，为了支持同时运行 x86 和 x64 应用程序，有两组独立/不同的 Windows 注册表 - 一组供 x86 应用程序访问，另一组供 x64 应用程序访问？ 例如，如果COM在x86注册表集中注册CLSID，那么x64应用程序将永远无法通过CLSID访问COM组件，因为x86/x64具有不同的注册表集？
那么，我的问题是我对上述示例的理解是否正确？ 我还想获得更多文档来学习这个主题，关于 x64 架构上的两套不同的注册表。 （我做了一些搜索，但没有找到任何有价值的信息。）
I heard on Windows x64 architecture, in order to support to run both x86 and x64 application, there is two separate/different sets of Windows registry -- one for x86 application to access and the other for x64 application to access? For example, if a COM registers CLSID in the x86 set of registry, then x64 application will never be able to access the COM component by CLSID, because x86/x64 have different sets of registry?
So, my question is whether my understanding of the above sample is correct? I also want to get some more documents to learn this topic, about the two different sets of registry on x64 architecture. (I did some search, but not found any valuable information.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我不久前遇到了这个问题。 简而言之，如果您在 64 位计算机上运行 32 位应用程序，那么它的注册表项位于 Wow6432Node 下。
例如，假设您有一个应用程序，其注册表信息存储在以下位置：
如果您将应用程序编译为 64 位二进制文件并在 64 位计算机上运行它，则注册表项位于上面的位置。 但是，如果您将应用程序编译为 32 位二进制文件并在 64 位计算机上运行它，那么您的注册表信息现在位于此处：
这意味着如果您在同一台计算机上同时运行应用程序的 32 位和 64 位版本然后他们将分别查看一组不同的注册表项。
I ran into this issue not long ago. The short answer is that if you run a 32 bit application on a 64 bit machine then it's registry keys are located under a Wow6432Node.
For example, let's say you have an application that stores its registry information under:
If you compile your application as a 64 bit binary and run it on a 64 bit machine then the registry keys are in the location above. However, if you compile your application as a 32 bit binary and run it on a 64 bit machine then your registry information is now located here:
This means that if you run both the 32 bit and 64 bit versions of your application on the same machine then they will each be looking at a different set of registry keys.
你的理解是正确的。 x64 应用程序不需要访问 x86 CLSID，因为它永远无法加载这些组件，反之亦然。
如果您想创建供 x86 和 x64 使用的组件，那么您需要创建一对 dll，一个为 x86 构建，另一个为 x64 构建，并将两者注册到注册表的相应部分。 System32文件夹中的regsrv32.exe将反常注册x64组件，SysWOW64文件夹中的regsrv32.exe将注册x86组件。
或者为任何 CPU 构建可供任一 CPU 架构使用的 .NET 程序集。
Your understanding is correct. There wouldn't be any need for a x64 app to access the x86 CLSIDs since it could never load those components anyway and vice versa.
If you want to create component for use by both x86 and x64 then you need to either create a pair of dlls one built for x86 and the other for x64 and register both in their appropriate parts of the registry. The regsrv32.exe in the System32 folder will perversely register the x64 component and the regsrv32.exe in the SysWOW64 folder will register the x86 component.
Alternatively build a .NET assembly for Any CPU which can used by either CPU architecture.
它们不是单独的注册表 - 一个是另一个的子节点，并且操作系统进行虚拟化以确保 32 位应用程序获取其密钥，而 64 位应用程序获取其密钥。
They aren't separate registries--one is a subnode of the other, and the OS does virtualization to make sure that 32bit apps get their keys and 64bit apps get their keys.
以下是有关 WOW64 注册表的 Wikipedia 文章，它可能会为您提供一些您正在寻找的信息：
http: //en.wikipedia.org/wiki/WOW64
Here is the Wikipedia article on the WOW64 registry which may give you some of the information you are looking for:
http://en.wikipedia.org/wiki/WOW64
我运行 x64 位机器作为我的桌面； 我从未遇到过不同注册表配置的任何问题。
根据 MSDN，显然存在差异：
http://msdn.microsoft.com/en-us /library/ms724072(VS.85).aspx
HTH
I run an x64 bit machine as my desktop; and I have never run into any issues with the different registry configurations.
Per MSDN, there is apparently a difference:
http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx
HTH
如何注册.NET程序集以在纯64位应用程序中用作COM？
问题：
默认情况下，如果您在构建设置中启用“注册 COM Interop”，则它不会注册 64 位类型库。
解决方案：
要在 64 位计算机上注册不在 GAC 中的程序集，请打开 cmd 窗口并执行以下操作：
这将消除使用本机 C++ 将 .NET 程序集实例化为 COM 对象时出现的“类未注册错误”。
How to register .NET assembly to be used as COM in pure 64-bit application?
Problem:
By default, if you enable "Register for COM Interop" in build settings, it DOES NOT register type library for 64-bit.
Solution:
To register your assembly which is not in GAC on a 64-bit machine, open cmd window and do:
This will eliminate "Class Not Registered Error" when using native C++ to instanciate .NET assembly as COM object.