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

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

1. 32位DLL只能驻留在32位进程中，64位DLL只能驻留在64位进程中。
2. 32位和64位进程只能使用松散耦合的消息系统进行通信，例如网络通信，这意味着它们可以使用COM/DCOM进行通信。
3. 32 位和 64 位 COM 组件具有不同的注册表项。组件通常仅在两个世界之一中注册，并且通常仅在两个世界之一中可见。
4. 如果 32 位进程使用带有 64 位调用标志的 CoCreateInstance，或者（我猜测这可能吗？）如果 64 位组件使用 CoCreateInstance，则它只能创建注册为 64 位 COM 组件的内容以某种方式在 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 位注册表并尝试创建进程外 64 位组件（如果 32 位注册表中没有注册）之类的操作？我看过 64 位 Office 的一些发行说明，其中 Microsoft 警告从 32 位应用程序访问 64 位 Excel 无法正常工作，但我知道有一个实例似乎可以正常工作。

对此有很好的技术事实参考吗？

中解释得很好MSDN 库文档 http://msdn.microsoft.com/en-us/library/ms693716%28VS.85%29.aspx对于 CLSCTX。很多规则，默认行为是：

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

• 如果托管服务器的计算机运行的是 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 文章。