64 位 Windows 上的 32 位和 64 位互操作性

Question

是否有详细的权威参考来讨论 32 位和 64 位进程之间的互操作性？根据谷歌搜索，我推断出：

1. 32 位 DLL 只能驻留在 32 位进程中，64 位 DLL 只能驻留在 64 位进程中。
2. 32 位和 64 位进程只能使用松散耦合的消息系统进行通信，例如网络通信，这意味着它们可以使用 COM/DCOM 进行通信。
3. 32 位和 64 位 COM 组件具有不同的注册表项。一个组件通常只在两个世界之一中注册，并且通常只在两个世界之一中可见。
4. 如果 32 位进程使用带有 64 位调用标志的 CoCreateInstance，或者（我猜这是可能的吗？）如果 64 -bit 组件以某种方式在 32 位注册表中注册，但在后台仍然创建为进程外 64 位进程，或者如果有一个 32 位 shell COM 组件创建 64 位组件然后重定向调用它？

这表明： 1. 32 位应用程序无法使用 GetObject 获取正在运行的 64 位版本的 Excel？或者可以吗？ 32 位与 64 位问题对运行对象表 (ROT) 有何影响？如果只安装了 64 位版本的 Office，32 位进程能否创建 Excel 实例？我认为答案是“否”，除非 32 位进程在其 CoCreateInstance 调用中使用 64 位标志，或者 Excel 也以某种方式在 32 位世界中注册了自己？

Microsoft 是否会自动执行任何操作，例如让 32 位进程中的 CoCreateInstance 检查 64 位注册表并在 32 位注册表中没有注册的情况下尝试创建进程外 64 位组件？我看到了一些来自 64 位 Office 的发行说明，其中 Microsoft 警告从 32 位应用程序访问 64 位 Excel 无法正常工作，但我知道有一个实例似乎可以正常工作。

这方面有很好的技术事实参考吗？

Answer 1

在 CLSCTX 的 MSDN Library docs 中有很好的解释。很多规则，默认行为是：

如果客户端和服务器都没有 指定首选项，然后：

• 如果托管服务器的计算机运行的是 Windows XP 或 无服务的 Windows Server 2003 安装 Pack 1 (SP1) 或更高版本，然后 COM 会更喜欢 64 位版本的 服务器（如果可用）；否则它 将激活 32 位版本的 服务器。

• 如果托管服务器的计算机运行的是 Windows Server 2003 安装 SP1 或更高版本，然后安装 COM 将尝试匹配服务器 架构给客户 建筑学。换句话说，对于一个 32 位客户端，COM 将激活一个 32 位服务器（如果可用）；否则 它将激活 64 位版本的 服务器。对于 64 位客户端，COM 将激活 64 位服务器，如果 可用的;否则会激活 32 位服务器。

如果您想覆盖此行为，请查看 MSDN 文章。