如何注册 32 位进程外 ATL COM 服务器以使其可用于 64 位程序？
我们有一个 32 位 ATL 进程外 COM 服务器。为了在注册表中注册自身，它调用 CComModule::UpdateRegistryFromResource() 并传递编译到同一可执行文件的资源中的 .rgs 文件的 ID。
在 32 位系统上运行良好，但在 64 位系统上运行不佳。显然，当 32 位 .exe 在 64 位 Windows 上运行时，其注册表访问会被重定向，因此它会将自身注册到“32 位 HKCR”中，因此 64 位程序看不到它的注册。
如何以最便宜且最可靠的方式在 64 位 HKCR 中注册相同的进程外服务器？
We have a 32-bit ATL out-proc COM server. In order to register itself in the registry it calls CComModule::UpdateRegistryFromResource() and passes an id of a .rgs file compiled into the resources of the same executable.
Works great on 32-bit systems, but not on 64-bit ones. Obviously when a 32-bit .exe runs on a 64-bit Windows its registry accesses are redirected and so it registers itself in "32-bit HKCR" and so 64-bit programs don't see its registration.
How do I register the same out-proc server in the 64-bit HKCR the cheapeast and most reliable way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我所知/记得你实际上不需要做任何特别的事情。
我检查了一个 32 位 ATL COM EXE 服务器，我专门编写了一个从 64 位代码调用的服务器（ http://www.pretentiousname.com/adobe_pdf_x64_fix/index.html ）并且注册代码完全是样板文件（除非我忘记了并且今天看不到我必须更改的内容）。
除非 64 位端调用 CoCreateInstance(Ex) 的代码专门传递 CLSCTX_ACTIVATE_64_BIT_SERVER，否则 COM 应在需要时自动检查 32 位注册表。 （即使 CLSCTX_ACTIVATE_64_BIT_SERVER 被传递，它仍然可能会传递。MSDN 并不完全清楚该标志是首选还是要求。我假设它无论如何都没有被传递。）
也许问题不在于 COM 服务器如何已注册但还有别的东西。或者也许注册了一个损坏的 64 位版本的服务器，可能是在开发/测试的早期，在 32 位服务器上选择了该版本并失败了？
顺便说一下，Windows 7 与早期操作系统版本上的注册表部分是 32/64 位分割的，但我从经验中知道，您不需要在 Vista、Windows 7 和 Server 上执行任何特殊操作2008 R2。我还没有亲自在其他操作系统版本（例如 XPx64）上进行测试。
As far as I can tell/remember you don't actually have to do anything special.
I have checked a 32-bit ATL COM EXE server which I wrote specifically to be called from 64-bit code ( http://www.pretentiousname.com/adobe_pdf_x64_fix/index.html ) and the registration code is completely boilerplate (unless I forgot and today cannot see something I had to change).
Unless the code on the 64-bit side calling CoCreateInstance(Ex) is specifically passing CLSCTX_ACTIVATE_64_BIT_SERVER, COM should automatically check the 32-bit registry if needed. (Even if CLSCTX_ACTIVATE_64_BIT_SERVER is passed it may still do. MSDN isn't entirely clear if that flag is a preference or a requirement. I'm assuming it isn't being passed anyway.)
Perhaps the problem isn't how the COM server is registered but something else. Or perhaps there is a broken 64-bit version of the server registered, maybe from earlier in development/testing, which is being chosen over the 32-bit server and failing?
By the way, there are differences in which parts of the registry are 32/64-bit split on Windows 7 vs earlier OS versions, but I know from experience that you don't need to do anything special on Vista, Windows 7 and Server 2008 R2. I haven't personally tested on other OS versions (e.g. XPx64).