如何让32位编译的程序在64位系统中正常运行
在64位的环境下编译32位的应用程序
在64位的环境下编译32位的应用程序1) 工具安装：a) 首先必须安装以下基本编译工具：sudo apt-get install gcc build-essential linux-header-`uname -r` dkmsb) 另外，为编译32bit程序，还需要安装以下软件包sudo apt-get install ia32-libs libc6-dev-i386 linux322) 最关键的东西是需要告知gcc编译器编译的平台是i386, 所以需要：a) 在configure前加上linux32b) 在configure后加上"CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"注：linux32 命令主要用来设置一下主机环境，其实影响的就是configure命令中--build, --host和--target三个选项。
linux32 命令使用前后区别：staff-1:~/src/lame-3.96.1# ./configurechecking build system type... x86_64-unknown-linux-gnuchecking host system type... x86_64-unknown-linux-gnustaff-1:~/src/lame-3.96.1# linux32 ./configurechecking build system type... i686-pc-linux-gnuchecking host system type... i686-pc-linux-gnu3) 如果编译的程序是32位的，所需要的动态链接库也必须是32位的，可以重新编译得到，也可以直接用sudo apt-get install libXXX:i386命令安装到编译主机上，":i386"即表示32位版本的该库。
系统小技巧：在64位系统中运行32位或16位程序
系统小技巧：在64位系统中运行32位或16位程序由于CPU和系统架构的更新，现行主流的Windows系统已经是64位。
然而许多人还恋恋不舍的一些老游戏或老程序已经没有了更新。
在64位的系统上运行这些程序，往往会出现运行故障。
如何才能解决这个烦心事？无奈的选择旧的不代表没有用就像其他硬件一样，CPU在过去的10多年间经历了重大的升级变革。
这不仅仅体现在核心的数量，还涉及到了体系结构的更新。
因此，现在的操作系统也围绕着CPU系统结构的升级而升级，依次出现了针对32位和64位处理器的版本。
然而，针对32位处理器并非第一个，在它之前还有16位处理器统治世界的时代。
更重要的是，目前仍在“服役”的一些应用程序仍然基于过时的体系结构，尽管Windows 10的增强兼容性选项可以创建一个与现行版本兼容的环境，但其仍然没有包含一些老软件所需的支持组件，因此致使一些老程序无法运行，因为这些程序的安装程序本身是基于16位的。
然而，旧的不代表没有用。
在没有新式应用程序替代的情况下，旧应用程序和游戏仍有其用武之地。
因此，需要找到能够运行它们的办法。
解决有道在新系统上运行旧程序目前Windows的主流版本已经发展到64位，但许多老程序仍未升级到64位版本。
好在目前主流的64位Windows 8.1或Windows 10都建有一种启用32位应用程序专门兼容机制，名为WoW64兼容层，它能够让我们在64位Windows上运行大多数32位应用程序，就像直接在32位Windows上运行一样。
但是，基于32位架构的老程序有一个明显的短板，它们只能使用2GB多的内存。
对于目前绝大多数电脑来说，内存利用率甚至还不足四分之一。
虽然目前多数电子游戏建立在64位架构之上，能够充分利用机器上安装的大容量内存空间，但许多老游戏由于采用32位架构设计，因此同样也无法充分利用现有内存空间。
1. 解决潜在的兼容性问题的基本方法避免软件与系统的不兼容的最好方法是安装最新版的64位电子游戏或应用程序。
64位系统兼容32位应用程序
所以當x64作業系統的IIS6想要跑FW1.1的程式，就必須將64bit的IIS降低為支援32bit。
我們可以在DOS模式下，執行下列指令
然後執行 aspnet_regiis.exe -s W3SVC/1/ROOT/虛擬目錄名稱
執行完後記得要到IIS的網頁延伸服務中，確認1.1.4322是否有允許，這樣才能跑唷！
但是可惜的是CrystalReport9.1似乎在x64平台上是不支援的，因為一直有問題，也暫時找不到答案。
C:\Inetpub\AdminScripts\cscript.exe adsutil.vbs get W3SVC/AppPools/Enable32BitAppOnWin64
成功後就已經將IIS降為32bit，但是由於IIS的32bit模式，介面不支援64bit，所以會發生在IIS中，虛擬目錄設定的屬性頁上，
注意： 2.0 的内部版本可能随当前发行的内部版本的变化而变化。这些步骤适用果你將IIS回復成支援64bit，
則這個屬性就又會出現...所以不見是正常的。
那重點來了，沒法下拉切換要執行的framework版本，那該怎麼設定目錄需求的framework版本？
其實這是需要透過指令來達成~~
首先先切換到Framework的目錄底下，譬如要設定1.1版，就在DOS模式切換到C:\WINDOWS\\Framework\v1.1.4322>
3. 键入以下命令，安装 2.0（32 位）版本并在 IIS 根目录下安装脚本映射：
%SYSTEMROOT%\\Framework\v2.0.50727\aspnet_regiis.exe -i
32位程序移植到64位平台前的准备工作
32位程序移植到64位平台前的准备工作我们最近完成的一个项目是移植一个大型的32位应用程序，它可在64位环境中支持11个操作系统平台，并且程序的源代码超过了30万行。
由于此32位程序是在几年前分成几部分开发而成，所以极有可能代码是由不同的开发者编写。
鉴于此，我们有理由怀疑，在64位移植中导致问题的类型不匹配，很有可能是在这几年中随着程序模块的添加与删除而引入的。
我们移植此32位程序到64位平台，是为了利用64位技术的先进之处--支持更大的文件、支持更大的内存、及64位计算，大体使用的方法是一个反复迭代的过程，不断地在一些细节问题上来来回回，如字节序、调整编译器选项等等，并时不时停下来查看是否达到了总体目标--遵从ANSI标准及源代码将来的可移植性。
第一步，我们研究了64位的系统资源，以充分了解11个操作系统平台上每一个的编译器选项、内存模型和编码方面的考虑。
作为全部工作的起点，我们在其中一个平台上打开了所有编译器警告，进行第一次构建，并仔细检查构建日志信息。
通过这些最初的构建、使用本地调试器、及之后使用如Parasoft''s Insure++（/）这样的工具，我们确定了一个开发蓝图，接下来，编制了一个清晰彻底的源代码目录清单，并在每次配置构建之后进行相应的检查。
经过最初的代码修改、调试、查阅构建日志，已经有足够的信息对现实中可能碰到的事件进行排序以确定优先次序。
在一个拥有所有基本功能的程序成功地通过我们的自动测试案例之后，移植工作总算到了一个转折点；此测试除了测试64位功能，也包含了向后兼容性测试。
如果你所移植的项目中有几个不同的64位平台，很可能要在其上一一测试，一旦程序可在第一个平台上正确运行，接下来就要测试下一个平台，如此这般下去。
然而，我们却发现了一个非常好的方法，可在同一时间，在所有的平台上进行工作，这是因为：·每一个编译器都在它的警告信息中都提供了不同的信息，仔细查看几个编译器产生的错误，可有助于我们定位问题区域。
从32位平台移植到64位平台的解决方案
从32位平台移植到64位平台的解决方案从32位平台移植到64位平台的解决方案一、概述1.移植的原因由于高性能服务器、数据库管理系统、电脑辅助设计工具，以及数字内容创作工具等应用方案均需要处理大量数据及占用存储器大量地址，因此为了满足这类应用方案的需要，64位技术便应运而生。
大约从九十年代后期起,就已经有64位机器问世,从去年到今年,Intel体系结构的芯片也开始出64位了.在UNIX环境下,已有几种操作系统支持64位环境了,据说微软也准备将Windows升级为64位操作系统。
可以预料,将来32位平台将不再是主流,唱主角的将是64位平台。
到时,客户环境也将全是64位平台。
因此,由于下面这样一些原因,使得某些应用程序从32位移植到64位:(1).工程、科学、商业---需要地址空间大于32位.大数据集:需处理的数据大于32位所能处理的极限;(大文件或数据库的内存映射是一种常用技术---通过把文件或数据库保存在内存,以避免经常的磁盘I/O操作.).计算需要1.程序复杂性;若是32位系统,32位程序,则虽然也能处理需大地址空间的应用,但程序将变得复杂;2.应用程序的吞吐量;SMP系统与并行编程不断用来处理科学计算与其他问题;这意味着,在32位系统上,多至12个高速处理器共享不超过4GB 的内存;64位系统则能为每个进程提供必要的内存与I/O资源,使得SMP能很好地进行扩展,并能提供科学,工程,商业领域所需的批量计算;3.典型的64位应用---决策支持、数据仓库、数据挖掘、基于因特网的应用、电子商务应用、Web服务器、多媒体服务器、数字密集的应用、一般数据库、大阵列操作应用.(2).现存32位系统---资源短缺限制了总体性能与吞吐量的提高现存32位多用户系统性能不是受限于CPU,而是受限于I/O带宽;而由分页引起的I/O又主要是由于内存不足于存储整个文件;如果有足够的内存可用,那么将显著减少分页,从而显著地改善系统性能..高压力环境下的32位应用程序:基于因特网的应用、电子商务应用、Web服务器、多媒体服务器、一般服务器、实时系统.(这些应用可从OS提供的大内存获得性能提高,因为OS会自动地为每个32位应用提供更多的内存与I/O资源.因此,64位系统能运行更多的并发的,大的32位应用程序.2.移植原则i.移植后的程序既可作为64位机器上的32位程序运行,又可作为64位机器上的64位程序运行;只要觉得有需要,就可将32位程序重编译为64位程序;ii.在64位平台上,不管是作为32位程序还是作为64位程序运行,其性能至少不应比32位程序在32位平台上运行的性能差;iii.32位进程与64位进程可同时在64位平台上运行.3.移植步骤将现有32位程序移植到64位时,由于AIX V4.3本身对32位程序与64位程序的支持,所以绝大部分的系统调用与C语言程序结构都不用改变,只要在源程序中遵守系统调用接口与相应的数据类型;但是,还是有一些由于数据类型长度的改变而引起的兼容性问题.因此从32位程序移植为64位程序一般必须经过下列步骤:(1).源程序的兼容性检查;这一步主要检查由于数据类型长度改变而引起的兼容性问题;(2).将从第(1)步检查出的兼容性源程序进行修改;(3).修改makefile文件;二、32位平台与64位平台1.平台的定义计算机系统是由硬件与软件两部分组成的。
64位操作系统调用32位的DLL说明
64位要用 C:\Windows\SysWow64下的 regist32注册另外 IIS下要设置应用是32位的单独执行vbs的话，也要用 C:\Windows\SysWow64下的cscript.exeX64上的IIS調用32位的DLL方法程序在编译的时候默认是Any CPU，即编译的程序可以在X86、X64系统平台上运行。
若希望我们的程序运行在X64系统上，我们所要做的仅仅是部署IIS，修改配置。
若想程序运行于IIS32位模式下，即运行在.net framwork32位下进行如下配置：1.修改IIS配置，允许32位程序运行。
cscript %systemdrive%/inetpub/adminscripts/adsutil.vbs setw3svc/appPools/enable32bitapponwin64 12.为IIS注册32。
注册后在IIS的web扩展里显示的是2.0.*32bit。
C:/WINDOWS//Framework/v2.0.50727/aspnet_regiis -i3.Web扩展里允许 2.0.*32bit运行。
运行的是w3wp32.exe进程。
二.64位模式1.cscript %systemdrive%/inetpub/adminscripts/adsutil.vbs setw3svc/appPools/enable32bitapponwin64 0默认就是0，若原来运行了32位程序，则需要重新设置为0。
2.C:/WINDOWS//Framework64/v2.0.50727/aspnet_regiis - i为IIS注册64为。
注册了64位的IIS在Web扩展里显示的是2.0.*。
3.Web扩展里允许 2.0.*运行。
运行的是w3wp.exe进程。
处理后还是没有出现“w3wp32.exe进程”。
但我的 Web扩展里面是有， 2.0的32位设置为允许的。
后新建了应用程序池，在新建的应用程序池的“高级设置”里面，把“启用32位应用程序”设置为true。
杀死进程，解决运行异常---让64位程序调用32位程序更流畅
杀死进程，解决运⾏异常---让64位程序调⽤32位程序更流畅由于32位程序中还调⽤了⼤量dll,导致每次调⽤时启动与关闭时都拖泥带⽔，致使出现运⾏异常runtime error R6016 - not enough space for thread data，经尝试发现，这个异常会随运⾏内存变化⽽变化，根本原因是因为多次调⽤32位程序后，导致没有内存空间创建新的进程。
经查找资料显⽰，这个问题经常出现在由C、C++、Vb6等写的代码中，⽽像C#中有⾃动内存管理，所以⼀般不会出现此类问题。
64位程序如下：1process.Kill()；⽴刻杀死⼀切由这个32位程序启动的进程，⽤⼀次，杀⼀次，不影响下次使⽤123 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34static void Main(string[] args){ //创建refpropPipe进程Process process = new Process();//将refpropPipe.exe放在与refprop64Hv相同路径下，相对路径引⽤process.StartInfo.FileName = @"C:\Users\Administrator\source\repos\refpropPipe\refpropPipe\bin\Debug\refpropPipe.exe"; //process.StartInfo.FileName = "refpropPipe.exe";process.Start();double value = 0;//向refpropPipe发送调⽤信息，即查询输⼊变量值using(NamedPipeClientStream pipeClientStream = new NamedPipeClientStream("request")){pipeClientStream.Connect();string input = Method + ","+ FluidName + ","+ InpCode + ","+ Units + ","+ Prop1 + ","+ Prop2;using(StreamWriter writer = new StreamWriter(pipeClientStream)){writer.WriteAsync(input);}}//接收refpropPipe返回的信息，即查询结果using(NamedPipeClientStream pipeClientStream = new NamedPipeClientStream("respose")){pipeClientStream.Connect();using(StreamReader reader = new StreamReader(pipeClientStream)){string val = reader.ReadToEnd();value = Convert.ToDouble(val);}}//process.WaitForExit();//process.Close();//不在等待了，直接杀死进程，省得拖泥带⽔，快哉快哉process.Kill();}。
32位程序移植到64位需要考虑的问题
32位程序移植到64位需要考虑的问题概述从32位到64位，根本性的区别在于两种数据类型发生了变化：long和pointer。
在32位环境下，两者长度都是32位，也就是4个字节；而在64位环境下都是8个字节。
所以当你把pointer或者long 型数据赋给int型时，会发生数据截断（data truncation)。
1、32位与64位数据模型之间的区别32位应用的数据模型我们称作ILP32(之所以这样命名，是因为int,long,pointer都是32位)，而64位应用则采用LP64模型（意味着long,pointer变成64位了，其他的不变）。
在当前的32位环境下，我们可以认为int,long,pointer是等价的，因为它们占用相同的字节，于是就有很多混用的情况；但是到了64位的时代，long和Poniter的大小都改变了，原来的假设不再成立。
2、注意int和pointer转换因为integer与pointer大小相同，所以32位代码中常常把pointer转换为int或者unsigned int，以便算术运算。
为了移植，你可以把pointer转换为unsigned long，因为long和pointer都是等长的，无论是在ILP32或LP64。
但是，为了使代码更清晰，推荐用uintptr_t，uintptr_t和intptr_t都需要包含头文件inttypes.h。
例如：下面代码在64位环境下编译出错：[cpp] view plain copy1.char *p = &something;2.p = (char *) ((int)p & PAGEOFFSET);3.4.% cc ..5.warning: conversion of pointer loses bits改用uintptr_t后，无论是32位或者64位都没问题：[cpp] view plain copy1.char *p = &something;2.p = (char *) ((uintptr_t)p & PAGEOFFSET);3、注意int和long转换在ILP32中，可能从未对int和long加以区分，因此，混用的情况非常多，看下面代码：[cpp] view plain copy1.int A = 0;2.long B = 0;3.long C = 0;4....5.A = B + C;6.7.8.% cc9.warning: assignment of 64-bit integer to 32-bit integer 4、结构体字节对齐及大小问题在结构体中，各个成员的起始地址都是对齐字节的倍数，例如：[cpp] view plain copy1.struct T2.{3.int i;4.long j;5.int k;6.char *p;7.};在ILP32中，sizeof(T)应该是16字节；在LP64中，应该是32！因为此时long/char *的对齐字节都变为8，为了保证满足对齐要求，i/k都被扩展为8字节了，又例如：[cpp] view plain copy1.struct T2.{3.char *p;4.long j;5.int i;6.int k;7.};此时，无需扩展，sizeof(T)=8+8+4+4=24.5、注意union例如：[cpp] view plain copy1.union U2.{3.double _d;4.long _l[2];5.};在ILP32中，两者大小相同都是8字节；移植到LP64,前者不变，后者为16字节，应改为：[cpp] view plain copy1.union U2.{3.double _d;4.int _l[2];5.};6、注意移位操作无类型的整数常量就是(unsigned) int 类型的，这可能会导致在位移时出现被截断的问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
如何让32位编译的程序在64位系统中正常运行操作系统从32位步入64位，对于用户来说是质的飞跃。
由于CPU读取数据宽度增加1倍，速度和精度都带来了跨跃。
同时，CPU的读写方式的改变，对于程序员来说，需要适应跟进。
虽然，64位系统支持32位程序，但是是有条件的，因为系统对CPU的操作有所变化，有的有32位上操作，就不能在64位在操作了。
比如，软件通过调用底层，通过汇编读写数据的源程序，在32位上运行自如，在64位上就出现问题，执行出错。
在开发工具方面，基于Java、.NET的工具可以很顺利地支持64位平台。
因为，它们不通过调用底层实现代码，而是基于.Net调用实施。
对于Delphi来说，由于它是与操作系统紧密相关的，与它代码，最终实现“32位程序可以在64位系统正常运行”的目的。
下面是笔者，初步实践，仅供同仁参考：
1、对于涉及到ASM代码的单元进行修改，采用API取代；
2、对于一些引用的读写硬件的单元，多数采用ASM代码，取消引用该类单元；
3、尽可能不使用第三方控件。
特别是，无源代码的第三方控件。
（内含ASM 代码）
4、修改后的读写硬件的单元，要分别在64位机器中，调试。
主要验证：
（1）可以运行（支持代码）。
（2）返回值32位与64位一致。
通过，上述代码改进。
编译后的程序。
在64位上正常运行。