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

Question

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

内核编译为 32 位 DLL，旨在用于 32 位应用程序。还有一个 shim 编译为 64 位 DLL，用于 64 位应用程序。shim 调用 CoCreateInstance() 来实例化核心并将调用重定向到核心。核心依赖于大量其他 32 位库。

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

现在 DCOM 注册看起来很奇怪。为什么将垫片注册到 DCOM 而不是核心？我希望 32 位内核应该注册到 DCOM 以在单独的进程中实例化并与 64 位使用者屏蔽。但显然它像目前所做的那样工作。用 DCOM 注册 64 位 shim 而不是 32 位内核有什么意义？

Answer 1

回想一下，您可以混合搭配 32 位和 64 位 DLL 和进程。在这种情况下，32 位内核不使用 DCOM，因为它可以直接加载到主机 32 位进程中。64 位 shim 需要 DCOM，因为它的开发人员正在利用 COM 在单独进程中托管内核的能力，即使在同一台机器上也是如此。这是必需的，因为 32 位内核无法加载到 64 位主机中。使用 DCOM 编组所有进出核心的调用，位于一个单独的 32 位进程中。这是一种最佳安排，因为对核心的调用不会通过 DCOM。开发人员很可能在他们的测试中利用了这一点，在 32 位进程中进行调试，没有 DCOM 的阻碍，直到核心被证明工作得很好，可以尝试从 64 位应用程序中调用它。