在64位注册表部分注册32位本地服务器是正确的还是错误的？

Question

一个作为32位本地服务器(.exe)实现的COM对象在64位Windows上注册时，默认情况下会被WOW64重定向(http://msdn.microsoft.com/en-us/library/aa384253.aspx)。当客户端请求实例时，系统通常会在两个部分中搜索，除非设置了显式上下文标志(CLSCTX_ACTIVATE_##_BIT_SERVER)。

因此，可以使用32位COM插件(作为本地服务器实现)与MS Office 2010 64位一起使用。只需要将MSO特定的注册表键写入64位部分即可(KEY_WOW64_64KEY)。

由于MS Office 2013 64位仅加载在64位注册表部分注册的COM对象，可能是因为它明确要求仅使用64位服务器。这似乎没有任何理由限制这样做。这种变化是否是在2010年和2013年之间无意中发生还是有意为之？

将32位本地服务器注册到64位部分可以解决问题，但是否符合规则？32位本地服务器是否可以注册到重定向的32位部分中，而不是64位部分中？这是否会忽略客户端的意图，还是一种表明与64位客户端兼容性的方式？

就我所知，MSO 2013不想支持32位插件，尽管技术上可能有可能。

编辑（更加精确）：我不是在问它是否有效（我知道它有效）。我不感兴趣的是让本来不打算这样做的事情起作用的技巧。这只是引发了我的问题，即哪些COM对象（本地服务器，也称为外部进程服务器）应该在64位部分注册：那些在64位中实现的还是可以由64位客户端使用的(即使它们是32位实现的)？

编辑（更加通用）：虽然我的问题涉及到MSO作为客户端实例化COM对象，但它可以更普遍地提出。想象一下一个作为32位EXE实现的自动化提供应用程序。默认情况下，它的自注册会被重定向到Wow6432Node，但这没有问题。当客户端请求实例时，系统将无论如何找到它（除非客户端限制仅使用64位服务器）。因此，通常不需要在64位部分注册，但对于32位EXE来说，这是错误的吗？这意味着什么，有什么后果？是否有任何规则、建议等？

- marx

Answer 1

在64位注册表中注册64位代理DLL是完全可以的。

但是不要在64位注册表中注册32位代理DLL。

- Eric Brown

---

我不是在谈论DLL（inprocserver），而是EXE（localserver）。由于DLL被加载到调用进程的地址空间中，因此位数必须匹配是显而易见的。而另一方面，在进程间场景中位数无关紧要是显而易见的（顺便说一下：在早期版本的WOW64中，当未指定inproc服务器或处理程序时，键HKLM...\CLASSID不仅被重定向，而且被反射。这意味着在本地服务器的情况下没有区别）。在64位部分注册32位EXE确实可以工作，但它是否符合规则呢？ - marx

EXE文件必须有代理DLL来处理编组。因此，唯一重要的是代理DLL的位数。 - Eric Brown

我不是COM方面的专家，但据我所知（并且有经验），代理DLL并非必需。我的COM对象托管在一个32位EXE中，通过LocalServer32键进行注册，没有存根、代理等等。它可以与64位客户端一起使用（默认情况下为MSO 2010，只有在64位部分也明确注册时才能使用MSO 2013）。我想系统会处理封送。 - marx

@marx 如果你所有的接口都是自动化兼容的，那可能是正确的。但在我的经验中，我总是需要一个代理 DLL。 - Eric Brown