32位編譯64位程序
A. 如何讓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位上正常運行。
B. 如何強制一個使用32lib的32位程序編譯成64位
編譯64位程序，不一定要編譯機器是64位的，但是32位機器默認安裝的gcc編譯環境還是不能用來編譯64位程序。編譯64位程序，需要加上-m64編譯器參數，默認安裝的gcc已經支持該參數，但是缺少64位機器指令相關的文件，所以不能編譯，會出現下面的錯誤 In file included from /usr/include/features.h:378, from /usr/include/assert.h:37, from ../../../include/tinyxml/tinystr.h:42, from ../../../src/tinyxml/tinystr.cpp:32: /usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: 沒有那個文件或目錄這時候需要安裝 gcc所有支持文件 sudo apt-get install gcc-multilib 將會安裝下列額外的軟體包： cpp-4.4 g++-4.4 gcc-4.4 gcc-4.4-base gcc-4.4-multilib lib64gcc1 lib64gomp1 libc6-amd64 libc6-dev-amd64 libgcc1 libgomp1 libstdc++6 libstdc++6-4.4-dev 建議安裝的軟體包： gcc-4.4-locales g++-4.4-multilib gcc-4.4-doc libstdc++6-4.4-dbg libmudflap0-4.4-dev libgcc1-dbg libgomp1-dbg libmudflap0-dbg libcloog-ppl0 libppl-c2 libppl7 lib64mudflap0 libstdc++6-4.4-doc 下列【新】軟體包將被安裝： gcc-4.4-multilib gcc-multilib lib64gcc1 lib64gomp1 libc6-amd64 libc6-dev-amd64下列軟體包將被升級：
C. 32位系統怎麼才能運行64位程序
（1）無需特別操作，windows7 64位系統直接兼容32位軟體，直接雙擊運行即可。
（2）windows xp64位是後期補的，第一個普及的家用64位系統是win7 x64，這是2009年發布的操作系統，經過微軟長達6年的打磨，已經對32位程序有很好的兼容性了，在win7 64位系統里運行32位程序不需要特別的操作，直接運行即可。
（3）如果直接運行後，出現兼容性問題，應該不是64位和32位程序的問題，而是win xp 和win7兩代操作系統之間的差異，比如許可權系統的不同，可以嘗試調整「兼容性」選項，調整方法如下：
① 滑鼠右鍵單擊：直接運行時有兼容性問題的程序，在彈出的右鍵菜單中點擊「屬性」。如下圖：
② 如下圖，切換到「兼容性」選項卡，在「以兼容模式運行這個程序」前面的復選框里「√」：
③ 展開下拉菜單，選擇兼容運行的系統版本，下圖是「windows10」的項目，已經沒有xp兼容模式了，windows7里還有xp兼容模式，可以嘗試選擇「Windows XP」，最後點擊下方的「確認」，設置完畢。調整設置後再雙擊運行該程序，就可以以兼容模式運行程序了：
D. 如何編譯64位dll程序，有幾種情況，在32位XP上用VC++6.0或者VS2010該怎麼編譯64位的dll。
在64位的操作系統上用vs軟體編譯的dll默認就是64位。
在32位XP上用VC++6.0編譯64位的dll，需要安裝sdk（最新版本是sdk2003），在開始菜單——sdk——open build environment window——windows server 2003 64-bit build environment——set win svr 2003 x64 build env進入命令行，從命令行調用msdev，將vc選項里的include和lib的第一個默認路徑設為sdk目錄下64位頭文件和庫的路徑，編譯出的dll似乎就是64位的了。這個是從網頁上看到的，沒實踐過。
在32位XP上使用vs2010就簡單多了，新建一個項目（解決方案），加入代碼，設置X64，編譯生成即可。
E. 32位系統編譯的程序能在64位下運行嗎
在32位的系統不能運行64位的程序，在64位的系統上可以運行32位的程序。
在32位下開發編譯和在64位下開發編譯是沒有區別的，重點在於生成的時候的選項，生成什麼平台軟體。是X86還是X64還是anycpu
F. opencv 32位機編譯64位程序
兩種無法修復，但可以在磁碟檢測中檢查到
G. 如何將32位游戲轉為64位
32位變成64位程序，除非你有源代碼，重新編譯成64位的。
所以2 和3 問題就不用答了。
第4個，是有內存上限的，32位理論是4g，但實際能識別的是3G多。
64位也有上限，這是理論值16TB，但實際上限是受 主板 和 微軟系統 的限制。目前Windows 7 64位版僅能使用最大為192GB內存。不光系統有限制，主板也有限制，現在支持最大32G，實際你的主板支持多大內存，可以在開始-運行里輸入CMD，在CMD里輸入：wmic memphysical get maxcapacity，然後換成g就是 主板 的最大支持內存
H. 32位程序移植到64位的要點
特別針對c/c++闡述，32位和64位源碼級的不同，歸根結底，就是機器字（設計指針的寬度）的位寬變化了，因此：
1、一些基本類型位寬變化了，還有一些類型位寬不確定，比如說int，相信99%的32位編譯器（未作統計）都將int視為32位有符號型，但在64位編譯器上，這點是不確定的，ms的編譯器，int型都還是32位有符號整型，但印象中存在某個平台的gcc編譯器將int位寬增加到64位。諸如此類，需要特別注意
2、強制類型轉換代碼需特別注意，特別是c開發人員，對於指針和整型的理解已爐火純青，藉由整型空間存儲指針的方法是很常用的（也是很方便的），由於強制轉換代碼的存在，編譯器並不會提示諸如64位到32位轉換中可能的信息損失，這也就導致了運行時可能的問題爆發。這一點需要特別注意，嚴查代碼各處的強制轉換。
3、模塊間調用，嚴格說這一點還是由位寬變化導致的，做法還是需要篩查類型是否匹配的問題
隨便想來，就上述三條逐一考察解決，應該就沒太多問題了，如有疏漏，還望擔待
I. 32位編譯器可以編64位程序嗎
VS不可以，不提供交叉編譯器
gcc可以
但是需要自行編譯（至少我不知道是否有人提供），把host設為i686-w64-mingw32
target設為x86_64-w64-mingw32 ！
J. windows 32位的程序調用64位的程序嗎
工作流程：
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系統