能力值：
( LV2，RANK：10 )
|
-
-
2 楼
我想过写两个32 64bit桩子，中间用IPC互联，这PLUGIN中间还反向抓取和CALL了不少东西...反向搭桥的代价有点大
|
能力值：
( LV2，RANK：10 )
|
-
-
3 楼
理论上可以，64位系统下的32位api最终调用的也是64位代码，具体的实现你去查一下
|
能力值：
![]()
(RANK：50 )
|
-
-
4 楼
直接比较麻烦。
由于32位环境下返回地址是32位的，需要写驱动实现类似WOW64的功能，外部函数返回后作出处理再返回主程序，而64位下的驱动那蛋疼的数字签名问题……
这里有个小思路：再建立一个32位进程，作为“中继”，所有调用32位函数的过程都通过它来完成，最后再通过各种进程间数据传递机制来实现。
这样性能损失可能会比较大，但方便。
|
能力值：
( LV2，RANK：10 )
|
-
-
5 楼
我找到这个，中继这个思路还是正确的
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
简单的情况用中继应该没问题，这个案例有些复杂，PLUGING一共初始化函数，主程序传了一个指针进去，然后里面PLUGIN反CALL和抽取主程序状态的调用估计都是在这个指针下完成的（都隐藏在PLUGIN SDK的一个400KB的static lib中），这些反向CALL和数据的抽取是个大问题，我觉得很有必要看看SDK生成的PLUGIN框架都私底下做了什么事情，然后完全模拟用中继方法接上
|
能力值：
( LV2，RANK：10 )
|
-
-
6 楼
DLL导出了个把个函数，若是用hexray提取C代码，修改后，然后编译，修复的工作量有多大？
|
能力值：
![]()
(RANK：50 )
|
-
-
7 楼
这个比较难说，RP好的话工作量 = 0，RP不好够忙很久的……
使用32位进程作为中继后，WOW64已经解决了大部分兼容性问题，对于指针传递，需要考虑到的问题如下：
1.32位DLL寻址范围只有4GB（假如内部有指针有效性检测代码的话，可能这个范围只有2GB)。
2.如果存在回调的话，反向调用又存在兼容性问题。
不知道回调涉及到哪些函数，这里只能给出简单的建议：
1.主程序中通过中继调用DLL的函数时只传递指向低2GB内存地址的指针。
2.利用MDL（Ring3下应该可以用FileMap）共享内存，避免调用指针。
不过预计还是得花大把的时间调试去研究回调，建议还是考虑下从整个程序架构的角度出发，试着把主程序分离成32位和64位两部分，同时运行两个进程。那些可能被回调的部分放在32位进程中，需要用到大内存或者64位运算的部分放在64位进程中。
|
|
|
|
