如何将32位编译二进制转换为64位

Veg*_*gie 9 c++ assembly x86-64 decompiler 32bit-64bit

背景: 我们已经获得了一个在Visual Studio中构建为32位Windows应用程序的软件产品.我们希望将此应用程序移植到64位.

此代码的关键任务组件是最初由第三方使用gFortran构建的黑盒静态库(.a文件).原来的开发人员已经过世了,我们能够获得的Fortran源代码不完整,而不是该库构建的版本(并且包含编译库中不存在的关键错误).他们没有使用VCS.

问题: 我想创建一个64位静态库,其代码在功能上等同于我们拥有的32位静态库.

我试过的:

  • 使用Snowman反编译器获取C++源代码,以64位重新编译.这被证明是不可能的,因为生成的代码使用看似特定于gcc的低级内部函数.它可能无论如何都不会起作用,因为这样的内在函数会编译为在64位中功能不相同的代码.我可能需要一个更好的反编译器.
  • 显然x86程序集是有效的x86_64程序集,所以我简要介绍了为什么我不能通过64位汇编程序运行程序集.原来ABI在64位不同,所以调用约定不匹配.可能我可以手动将函数调用转换为正确的约定,其余部分保持不变,但这可能是一个棘手的问题.意见?

Dai*_*Dai 10

您可以保留32位二进制库,但将其加载到32位主机进程中,并使用某种IPC(共享内存,命名管道,本地环回网络连接等)将数据传输到64-或从64-位过程.

这种方法的另一个优点是,如果Fortran代码崩溃,那么它只会关闭子主机进程,而不是你的主应用程序,你的程序可以立即再次启动它; 如果它是一个单线程Fortran程序,那么你可以启动多个实例以实现多核并行.

  • @JesperJuhl:这个评论可能适用于这个问题,而不是这个答案.你知道**接口,这就是你需要按照本答案中解释的方式使用黑盒子.这已经不比OP已经做的那么多了. (5认同)
  • @JesperJuhl:这不是黑客。从本质上讲,COM替代流程如何(以及为什么)起作用。启动代理流程是一个已解决的问题。IPC是一个已解决的问题。 (3认同)
  • 这是一个黑客(充其量).保持前进的乐趣. (2认同)