在WOW64上注册64位部分的32位进程外COM对象 [英] Register 32bit out-of-process COM object in 64bit part on WOW64
问题描述
在64位窗口上实现为32位本地服务器（.exe）的COM对象默认由WOW64重定向（http://msdn.microsoft.com/en-us/library/aa384253.aspx ）。当
客户端请求实例时，系统通常会在两个部分中进行搜索，除非设置了显式上下文标志（CLSCTX_ACTIVATE _ ## _ BIT_SERVER）。因此，64位客户端可以实例化32位COM对象，反之亦然。
在我的例子中，COM对象是MS Outlook的加载项。从MS Outlook 2010 64位开始，只需要将Outlook特定密钥（HKLM \Software \ Microsoft \Office\Outlook\Addins \< ProgID>）写入注册表的64位部分。虽然搜索
的加载项显然只包括64位部分，但实例化它们可能是通过系统完成的并且工作正常。从Outlook 2013 64bit实例化COM对象失败，如果它仅在32位部分注册。在64位
部分注册时，它也有效。
这导致两个问题：
1.）Outlook 2010和2013之间的这种变化是偶然还是故意的？加载项是否因为任何原因而被禁止进行32位进程外COM对象？
2.）5月32位进程外COM对象被注册在注册表的64位部分还是必须在重定向的32位部分？它会忽视客户的意图，还是一种向64位客户发出兼容性信号的方式？应该在64位部分注册哪些COM对象
：64位实现的那些或64位客户端可以使用的那些（即使它们以32位实现）？
请注意：我不是在讨论客户端和服务器的位数必须匹配的进程内服务器（.dll）。我不是在问它是否有效（我知道它确实如此）。我并不感兴趣使得工作有意无效。
虽然我的问题是将MSO称为客户端实例化COM对象，但第二个可以更广泛地被问到：想想提供自动化的应用程序，实现为32位exe。默认情况下，它的自我注册被重定向到Wow6432Node，但是
这没问题。当客户端请求实例时，系统仍会找到它（除非客户端仅限制为64位服务器）。因此，通常没有必要将32位exe注册到64位部分，但这是错误的吗？
是什么意思，后果是什么？是否有任何规则，建议......？
嗨klammeraffe，
欢迎在这里！
这个论坛是讨论如何开发应用程序而不是讨论为什么设计为这个。
如果你还想知道原因，请在以下问题上提出此问题：
感谢您的理解！
问候！
A COM object implemented as 32bit local server (.exe) registering itself on 64bit windows gets redirected by WOW64 by default (http://msdn.microsoft.com/en-us/library/aa384253.aspx). When
a client requests an instance, the system will normally search in both parts, unless explicit context flags are set (CLSCTX_ACTIVATE_##_BIT_SERVER). Therefore 64bit clients can instantiate 32bit COM objects and vice versa.
In my case, the COM object is an add-in for MS Outlook. As of MS Outlook 2010 64bit it was just necessary to write the Outlook specific keys (HKLM\Software\Microsoft\Office\Outlook\Addins\<ProgID>) to the 64bit part of the registry, too. While searching
for add-ins obviously includes the 64bit part only, instantiating them is presumably done via the system and works fine. As of Outlook 2013 64bit instantiating the COM object fails, if it is registered in the 32bit part only. When registering in the 64bit
part too, it works.
This leads to two questions:
1.) Was this change between Outlook 2010 and 2013 made accidentally or intentionally? Are add-ins implemented as 32bit out-of-processes COM objects banned due to any reason?
2.) May 32bit out-of-processes COM objects be registered in the 64bit part of the registry or must they be in the redirected 32bit part? Would it disregard a client's intent or is it a way to signal compatibilty with 64bit clients? Which COM objects should
be registered in the 64bit part: Those implemented in 64bit or those that can be used by 64bit clients (even if they are implemented in 32bit)?
Please note: I'm not talking about in-process servers (.dll) for which bitness of client and server must match. I'm not asking if it works (I know that it does). I'm not interested in tricks to make things work that are not intended to.
Although my questions refer to MSO as client intantiating a COM object, the second one can be asked more generally: Think of an Application providing automation, implemented as 32bit exe. By default it's self registration gets redirected to Wow6432Node, but
that's no problem. When a client requests an instance, it will be found by the system anyway (unless the client restricts to 64bit servers only). Therefore it's usually not necessary to register the 32bit exe to the 64bit part too, but is it wrong? What does
it mean, what are the consequences? Are there any rules, recommendations, ...?
Hi klammeraffe,
Welcome here!
This forum is for discussing how to develop app not for discussing why it is designed as this.
If you still want to know the reason, please ask this question as suggestions on :
Thanks for your understanding!
Regards!
这篇关于在WOW64上注册64位部分的32位进程外COM对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
