Windows 64位注册表v. 32位注册表。

时间:2022-09-01 08:24:00

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?

我在Windows x64架构上听说过,为了支持运行x86和x64应用程序,有两个独立的/不同的Windows注册表——一个用于x86应用程序,另一个用于x64应用程序访问?例如,如果一个COM在x86的注册表中注册了CLSID,那么x64应用程序将永远无法通过CLSID访问COM组件,因为x86/x64有不同的注册集?

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.)

所以,我的问题是我对上述样本的理解是否正确?我还想获得更多的文档来了解这个主题,关于x64架构上的两套不同的注册表。(我搜索了一下,但没有找到任何有价值的信息。)

6 个解决方案

#1


52  

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.

不久前我遇到了这个问题。简短的回答是,如果在64位机器上运行32位应用程序,那么它的注册表键位于wow6432节点下。

For example, let's say you have an application that stores its registry information under:

例如,假设您有一个应用程序,它将注册表信息存储在下面:

HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX

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:

如果将应用程序编译为64位二进制文件,并在64位机器上运行,那么注册表项就位于上述位置。但是,如果将应用程序编译为32位二进制文件并在64位机器上运行,那么您的注册表信息就位于这里:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX

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.

这意味着,如果在同一台机器上运行应用程序的32位和64位版本,那么它们将分别查看不同的注册表键集。

#2


6  

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.

你的理解是正确的。x64应用程序不需要访问x86 clsid,因为它永远无法加载这些组件,反之亦然。

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.

如果您想要创建用于x86和x64的组件,那么您需要创建一个为x86构建的dll,另一个用于x64,并在注册中心的适当部分注册。regsrv32。在System32文件夹中,exe将会异常地注册x64组件和regsrv32。在SysWOW64文件夹中exe将注册x86组件。

Alternatively build a .NET assembly for Any CPU which can used by either CPU architecture.

或者为任何一个CPU架构使用的任何CPU构建一个。net程序集。

#3


4  

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.

它们不是单独的注册中心——一个是另一个的子节点,而操作系统则是通过虚拟化来确保32位应用程序得到它们的密钥,而64位应用程序得到它们的密钥。

#4


1  

Here is the Wikipedia article on the WOW64 registry which may give you some of the information you are looking for:

这是*上关于WOW64注册表的文章,它可能会给你一些你正在寻找的信息:

http://en.wikipedia.org/wiki/WOW64

http://en.wikipedia.org/wiki/WOW64

#5


1  

I run an x64 bit machine as my desktop; and I have never run into any issues with the different registry configurations.

我运行一个x64位机作为我的桌面;我从来没有遇到过不同注册表配置的问题。

Per MSDN, there is apparently a difference: http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx

每个MSDN,显然有一个不同之处:http://msdn.microsoft.com/en-us/library/ms724072(vs85).aspx。

HTH

HTH

#6


1  

How to register .NET assembly to be used as COM in pure 64-bit application?

如何在纯64位应用程序中注册。net程序集作为COM ?

Problem: By default, if you enable "Register for COM Interop" in build settings, it DOES NOT register type library for 64-bit.

问题:默认情况下,如果在build settings中启用“COM Interop注册”,它就不会为64位的类型库注册。

Solution: To register your assembly which is not in GAC on a 64-bit machine, open cmd window and do:

解决方案:在64位机器上注册没有GAC的程序集,打开cmd窗口并执行:

cd c:\windows\microsoft.net\framework64\v2.x.xxxxx
regasm /codebase "path to your compiled assembly dll"

This will eliminate "Class Not Registered Error" when using native C++ to instanciate .NET assembly as COM object.

这将消除“类未注册错误”,当使用native - c++来instanciate . net程序集作为COM对象时。

#1


52  

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.

不久前我遇到了这个问题。简短的回答是,如果在64位机器上运行32位应用程序,那么它的注册表键位于wow6432节点下。

For example, let's say you have an application that stores its registry information under:

例如,假设您有一个应用程序,它将注册表信息存储在下面:

HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX

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:

如果将应用程序编译为64位二进制文件,并在64位机器上运行,那么注册表项就位于上述位置。但是,如果将应用程序编译为32位二进制文件并在64位机器上运行,那么您的注册表信息就位于这里:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX

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.

这意味着,如果在同一台机器上运行应用程序的32位和64位版本,那么它们将分别查看不同的注册表键集。

#2


6  

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.

你的理解是正确的。x64应用程序不需要访问x86 clsid,因为它永远无法加载这些组件,反之亦然。

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.

如果您想要创建用于x86和x64的组件,那么您需要创建一个为x86构建的dll,另一个用于x64,并在注册中心的适当部分注册。regsrv32。在System32文件夹中,exe将会异常地注册x64组件和regsrv32。在SysWOW64文件夹中exe将注册x86组件。

Alternatively build a .NET assembly for Any CPU which can used by either CPU architecture.

或者为任何一个CPU架构使用的任何CPU构建一个。net程序集。

#3


4  

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.

它们不是单独的注册中心——一个是另一个的子节点,而操作系统则是通过虚拟化来确保32位应用程序得到它们的密钥,而64位应用程序得到它们的密钥。

#4


1  

Here is the Wikipedia article on the WOW64 registry which may give you some of the information you are looking for:

这是*上关于WOW64注册表的文章,它可能会给你一些你正在寻找的信息:

http://en.wikipedia.org/wiki/WOW64

http://en.wikipedia.org/wiki/WOW64

#5


1  

I run an x64 bit machine as my desktop; and I have never run into any issues with the different registry configurations.

我运行一个x64位机作为我的桌面;我从来没有遇到过不同注册表配置的问题。

Per MSDN, there is apparently a difference: http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx

每个MSDN,显然有一个不同之处:http://msdn.microsoft.com/en-us/library/ms724072(vs85).aspx。

HTH

HTH

#6


1  

How to register .NET assembly to be used as COM in pure 64-bit application?

如何在纯64位应用程序中注册。net程序集作为COM ?

Problem: By default, if you enable "Register for COM Interop" in build settings, it DOES NOT register type library for 64-bit.

问题:默认情况下,如果在build settings中启用“COM Interop注册”,它就不会为64位的类型库注册。

Solution: To register your assembly which is not in GAC on a 64-bit machine, open cmd window and do:

解决方案:在64位机器上注册没有GAC的程序集,打开cmd窗口并执行:

cd c:\windows\microsoft.net\framework64\v2.x.xxxxx
regasm /codebase "path to your compiled assembly dll"

This will eliminate "Class Not Registered Error" when using native C++ to instanciate .NET assembly as COM object.

这将消除“类未注册错误”,当使用native - c++来instanciate . net程序集作为COM对象时。