这个奇怪的32位/ 64位互操作解决方案如何工作？

Question

我目前正在维护我们几年前外包的软件，而且文档记录很少。该部分是供第三方应用程序使用的COM服务器和执行所有必要部署的安装程序。

核心编译为32位DLL，旨在用于32位应用程序。此外，还有一个编译为64位DLL的填充程序，用于从64位应用程序中使用。该填充程序调用CoCreateInstance（）来实例化核心并将调用重定向到核心。核心依赖于大量其他32位库。

32位内核通常与进程内服务器一样注册 - 在HKCR \ CLSID下有一个条目，包括核心类ID和InprocServer32下库的路径。 64位填充程序以相同的方式注册，并且还为64位填充程序引入了应用程序ID - 它在HKCR \ CLSID下添加并在DCOM中注册 - 在DCOM控制台中有一个具有该应用程序ID的条目。 / p>

现在DCOM注册看起来很奇怪。为什么垫片会被注册到DCOM而不是核心？我希望32位内核应该注册到DCOM，以便在一个单独的进程中实例化，并与64位消费者屏蔽。但显然它现在已经完成了。注册64位垫片而不是使用DCOM的32位内核是什么意思？

Answer 1

回想一下，您可以混合使用32位和64位DLL和进程。在这种情况下，32位内核不使用DCOM，因为它可以直接加载到主机32位进程中。 64位填充程序需要DCOM，因为它的开发人员正在利用COM在单独进程中托管核心的能力，即使在同一台机器上也是如此。这是必需的，因为32位内核无法加载到64位主机中。使用DCOM编组来自核心的所有调用，坐在一个单独的32位进程中。这是一种最佳安排，因为调用核心不会超过DCOM。开发人员非常可能在测试中利用这一点，在32位进程中进行调试，而DCOM不会受到阻碍，直到核心被证明能够很好地运行以尝试从64位应用程序调用它。