小编Kha*_*ish的帖子

是否有一个很好的权威参考,讨论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无法正常工作,但我知道有一个实例似乎只是工作.

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

在动态加载libpng.dll时,从libpng13.dll升级到1.5版之后,编译器开始报告这个未解析的外部:png_set_longjmp_fn

我该怎么办呢？