操作系統從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位上正常運行。
