64位进程调用32位dll的解决方法 / 程序64位化带来的问题和思考

From:http://blog.sina.com.cn/s/blog_69ae4db50100mgav.html

最近做在Windows XP X64,VS2005环境下做32位程序编译为64位程序的工作，遇到了一些64位编程中可能遇到的问题：如内联汇编（解决方法改为C/C++代码），long类型的变化，最关键的遇到了64位进程需要调用32位dll的问题。由于有一些32位dll没有源代码，无法重新编译为64位dll，所以只能想办法解决64位进程调用32位dll问题,这个问题让我很是挠头了几天。

相关资料：
微软公司的官方网站针对这个问题描述如下：
在64位的windows系统中，一个64位进程不能加载一个32位dll，同理一个32位进程也不能加载一个64位dll。但是，64位windows支持64位和32位进程（包括本机或跨机）间进程间通信（RPC）。在64位windows中，一个进程外32位COM服务器能够与64位客户端进行通信，同样一个进程外64位COM服务器也能与32位客户端进行通信。因此，如果你有一个32位COM无法识别的DLL，你可以将它封装到一个进程外COM服务器中并在一个64位进程中用COM配置调用DLL。（最后一句我也看不太懂！！哈哈哈）

验证：
工作流程：
1.创建一个进程外COM服务器(EXE)。
2.将32位dll的接口函数封装为COM服务器的相关接口。
3.注册COM服务器*.exe /regserver  (注销 *.exe /unregserver)。
4.64位进程调用32位COM服务器接口，成功。从而曲线实现了64位进程调用32位dll。

具体步骤：
我首先创建了一个简单的dll工程，只输出一个函数int c = add(int a,int b); 生成lib和dll
然后创建一个进程外COM(EXE类型)，内部链接dll，添加方法Method: Add(long *c)
{ *c = add(1,2);}编译生成。
然后注册COM，*.exe /regserver
最创建一个64位WIN32工程验证64位环境下方法调用是否正确，经验证正确！！！

结论：以上方法可以解决64位进程调用32位dll的问题

32位进程调用64位dll应该也可以通过这种方法解决，原因64位windows系统下安装了32位和64位两套COM系统

 

程序64位化带来的问题和思考

1. 指针和long的转换
这是最基本的处理部分，由于32位系统下地址是32位，所以很多代码里都会存在这样的转换:
void* pData;
LONG lData;
lData = (LONG)pData;
现在地址是64位了，所以原来的这种转换就会导致地址高4Byte丢弃的问题.
这种转换向来被认为不安全，但还是大量出现，实际程序员代码的时候只要用一个指针保留就可以，完全没有必要用一个long保留，同样的问题也会出现在函数指针的保留.
思考:
所谓的存在即合理的思维在作怪吧，很多程序员认为这么做程序运行的好好的，所以不管是否有风险还照样这么写，实际上改成安全写法代码多不了多少.
当然不排除很多程序员对16位、32位、64位完全没有概念的.
还有一点可能是微软的windows消息给人以误导，消息的WPARAM和LPARAM中常会夹带数据指针，然后强制类型转换，但是看一下它们的定义，其中隔了一层，虽然只是语法上的小小手脚，但是绝对是有先见之明, 而很多人只会依样画葫芦而未明白期间的巧妙.

2. PE Import和Export Table的变化
程序中用到了PE hack，由于之前有人发现vista 32下原来所需要替换的一个import table中的函数找不到了，结果竟然去修改了export table, 姑且不谈修改export table的危险吧，结果vista 64的时候发现PE格式有了小小的变更.
MS将Import table中的地址转成了64bit，但是export table却还是32bit，估计其认为代码不可能大于4GB吧，这样就会发现更改export table变得很难，因为不同的dll会被load在不同的地址段，其间差距会大于4GB，所以只有将自己的dll强制定义在和目标dll相同的4GB范围内.
回头来说这种更改是极其危险的，因为对于export table OS会尽量保持全局唯一，所以一旦你的dll退出未能正确恢复原有的值，会造成其他所有使用到这个dll的程序crash.
最终我发现需要hack的那个函数放在了delayload import table中，简单的修改就解决了问题.
如果这个问题最终找不到而还是采用修改export table的方法，那么就会很惨，测试部门已经发现了经常性的系统crash.
思考:
这里出现了弯路，这个弯路项目的时间压迫难辞其咎，但是程序员未能自己去分析问题是更大的问题，vista在很多方面都保留了很好的兼容性，去分析下windows的目录就会发现基本和xp区别不大，所以很多基础dll的功能也没有变化(这一点让我感觉到vista并未如其发表的那样70%代码重写)，在分析dll的时候只要稍微仔细点就会找到问题很简单.
另一个问题就是MS在定义PE格式的时候的确有很高的前瞻性，很好的保持了松耦合的能力，其实PE格式在2001年后就基本没有什么大的更改，那时大家还基本没有64位的概念，这一点是需要学习的，但是同样对于export table没有扩展到64bit我还是保留意见，难道真的认为4GB不会超过？当年盖茨大叔不是宣称640KB就够了吗^.^

3. DelayLoad的问题
DelayLoad这个特性在VC6开始出现，一般大家不会去接触，包括我自己，要不是这次机会也不会去看.
推荐一篇文章
http://www.microsoft.com/msj/0200/hood/hood0200.aspx
有详细的阐述，有兴趣可以自己看一下，其实其原理很简单，主要是在使用到某个dll的接口的时候再去load这个dll，这样可以节约空间，因为有些dll中的接口可能在程序周期中永远不会用到, 而且如果某个dll没有，如果没有用到，那么整个程序也能继续执行.
这真的是一个巧妙的设定, 虽然在第一次呼叫的时候会有小小的性能损失，并且代码也会稍微大一点，但是可能会带来更大的空间节省.
但是随即带来的思考, 为什么这么好的一个东西会那么生疏呢？个人考虑有以下原因:
1. 这种技术显然对于很多人来说过于底层了，有多少人在意编译出来的程序是怎么样存放，又是如何被加载运行的呢？
2. DelayLoad带来的好处对很多人不可见，只要我的程序编译通过，并且可以正确执行就可以了，节省了那么些空间或者扩展兼容有必要考虑吗？
3. 现在的硬件太好了，何必要去做这种优化呢？内存消耗多了，没什么嘛去买1GB内存插上不久解决了？
4. 编译系统不够智能，可能Visual Studio做的更加智能些，自动去分析然后产生delay load会更好吧？