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

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

32位DLL只能驻留在32位进程中，而64位DLL只能驻留在64位进程中

32位和64位进程只能使用松散耦合的消息系统（如网络通信）进行通信，这意味着它们可以使用COM/DCOM进行通信

32位和64位COM组件具有不同的注册表项。组件通常只在两个世界中的一个世界中注册，并且通常只在两个世界中的一个世界中看到

如果32位进程使用带有64位调用标志的CoCreateInstance，则只能创建注册为64位COM组件的内容，或者（我猜这是可能的吗？）如果64位组件以某种方式在32位注册表中注册，但在后台仍然创建为进程外64位进程，或者如果有一个32位shell COM组件创建64位组件，然后重定向对它的调用

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

如果32位注册表中没有注册任何组件，Microsoft是否会自动执行诸如让32位进程中的CoCreateInstance检查64位注册表并尝试创建进程外64位组件之类的操作？我在64位Office中看到过一些发布说明，其中Microsoft警告说，从32位应用程序访问64位Excel不起作用，但我知道有一个实例似乎起作用

---

是否有一个很好的技术事实参考？

在CLSCTX中对其进行了很好的解释。很多规则，默认行为是：

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

• 如果承载服务器的计算机运行的是Windows XP或 不带服务的Windows Server 2003 安装了包1（SP1）或更高版本，然后 COM更喜欢64位版本的 服务器（如果可用）；否则它 将激活32位版本的 服务器

• 如果承载服务器的计算机正在运行Windows server 2003 安装了SP1或更高版本，然后是COM 将尝试匹配服务器 面向客户机的体系结构 建筑学换句话说，对于 32位客户端，COM将激活 32位服务器（如果可用）；否则 它将激活64位版本的 服务器。对于64位客户端，COM 将激活64位服务器，如果 可用的；否则它将被激活 32位服务器

---

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

谢谢，我低估了MSDN部分。那么，为什么本文要创建一个64位COM包装器，它只与32位COM包装器交互？这应该是不必要的，因为只有32位COM组件，在32位和64位世界中都应该是同样可用的，假设函数等的适当编组？另请看底部的“您应该知道的”部分，它警告不兼容。为什么？DDJ文章重点介绍如何使32位COM服务器在64位进程中工作，包装器必须是64位的。Office文章警告进程内COM服务器不兼容。只有进程外服务器才能弥补这一差距