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位进程使用CoCreateInstance和64位调用标志,那么它只能创建一个注册为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位世界中注册了自己？

Microsoft是否自动执行任何操作,例如从32位进程获取CoCreateInstance检查64位注册表并尝试创建一个进程外的64位组件(如果在32位注册表中没有注册)？我已经看到64位Office的一些发行说明,其中Microsoft警告从32位应用程序访问到64位Excel无法正常工作,但我知道有一个实例似乎只是工作.

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

Answer 1

在CLDNCTX 的MSDN Library文档中对此进行了很好的解释.很多规则,默认行为是:

如果客户端和服务器都没有指定首选项,则:

• 如果承载服务器的计算机运行的是安装了Service Pack 1(SP1)或更高版本的Windows XP或Windows Server 2003,则COM将更喜欢64位版本的服务器(如果可用); 否则它将激活32位版本的服务器.

• 如果承载服务器的计算机运行的是安装了SP1或更高版本的Windows Server 2003,则COM将尝试将服务器体系结构与客户端体系结构相匹配.换句话说,对于32位客户端,COM将激活32位服务器(如果可用); 否则它将激活64位版本的服务器.对于64位客户端,COM将激活64位服务器(如果可用); 否则它将激活32位服务器.

如果要覆盖此行为,请查看MSDN文章.