默认情况下，作为 32 位本地服务器 (.exe) 在 64 位窗口上注册的 COM 对象会被 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 年之间的这种变化是无意的还是有意的？
将32bit本地服务器注册到64bit部分解决了问题，但是符合规则吗？可以在 64 位部分注册 32 位本地服务器还是必须在重定向的 32 位部分中注册？它会无视客户的意图，还是表示与 64 位客户端兼容的一种方式？
据我了解，MSO 2013 不希望支持 32 位插件，尽管技术上可能。
编辑（更准确地说）：我不是在问它是否有效（我知道它有效）。我对使事情不打算工作的技巧不感兴趣。它只是让我想到应该在 64 位部分注册哪些 COM 对象（本地服务器，也就是进程外服务器）的问题：那些在 64 位中实现的对象或那些可以被 64 位客户端使用的对象（即使它们是在 32 位中实现的） )?
编辑（更笼统）：虽然我的问题将 MSO 称为客户端实例化 COM 对象，但可以更普遍地询问它。想想一个提供自动化的应用程序，实现为 32 位 EXE。默认情况下，它的自我注册被重定向到 Wow6432Node，但这没问题。当客户端请求实例时，系统无论如何都会找到它（除非客户端仅限于 64 位服务器）。因此通常也不需要注册到 64bit 部分，但它是错误的（对于 32bit EXE）？这是什么意思，有什么后果？是否有任何规则、建议……？