你在原機器上使用的是32位編譯器，在新系統上使用的是64位的編譯器，64位編譯出來的程式，不是如何進行除錯？
uj5u.com熱心網友回復：
《如何讓32位編譯的程式在64位系統中正常運行》http://blog.csdn.net/lyhoo163/article/details/26615191
uj5u.com熱心網友回復：
http://http://blog.csdn.net/lyhoo163/article/details/26615191uj5u.com熱心網友回復：
如何讓32位編譯的程式在64位系統中正常運行作業系統從32位步入64位，對于用戶來說是質的飛躍。由于CPU讀取資料寬度增加1倍，速度和精度都帶來了跨躍。同時，CPU的讀寫方式的改變，對于程式員來說，需要適應跟進。雖然，64位系統支持32位程式，但是是有條件的，因為系統對CPU的操作有所變化，有的有32位上操作，就不能在64位在操作了。比如，軟體通過呼叫底層，通過匯編讀寫資料的源程式，在32位上運行自如，在64位上就出現問題，執行出錯。
在開發工具方面，基于Java、.NET的工具可以很順利地支持64位平臺。因為，它們不通過呼叫底層實作代碼，而是基于.Net呼叫實施。對于Delphi來說，由于它是與作業系統緊密相關的，與它相關的資料型別，作業系統的SDK等變化都會很大，所以從32位到64位的遷移就會出現一些困難。至于匯編語言，它的變化就會更大了。
最近筆者，遇到一個問題：在32位上編譯的(C/S)三層資料庫管理系統，由于客戶服務器作業系統由32位升級到64位，以至原服務器端（程式）不能在64位服務器系統上運行。為此，筆者通過改進代碼，最終實作“32位程式可以在64位系統正常運行”的目的。
下面是筆者，初步實踐，僅供同仁參考：
1、對于涉及到ASM代碼的單元進行修改，采用API取代。
2、對于一些參考的讀寫硬體的單元，多數采用ASM代碼，取消參考該類單元。
3、盡可能不使用第三方控制元件。特別是，無源代碼的第三方控制元件。（內含ASM代碼）
4、修改后的讀寫硬體的單元，要分別在64位機器中，除錯。主要驗證：
（1）可以運行（支持代碼）。
（2）回傳值32位與64位一致。
通過，上述代碼改進。編譯后的程式。在64位上正常運行。
uj5u.com熱心網友回復：
64位系統編譯的程式，只要你編譯的目標是32位程式，正常情況下可以在32位下運行。我最近一直用64的系統，目前沒發現任何問題。uj5u.com熱心網友回復：
64位系統編譯的程式，可以在32位下運行。但是32位系統編譯32位程式后，不一定能在64位中，正常運行，參照3樓的辦法，就可以很好地解決，實作32位編譯的程式，完善地在64位中運行。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/98957.html
標籤：VCL組件開發及應用
上一篇：fastreport預覽時只有一頁，點列印就多列印一頁空白頁，求救！！！！
下一篇：為什么