對於64位還是32位，首先要從概念上把其理清，我覺得這可以分為三個層次：
硬件
主要是指CPU的指令集，寄存器，以及地址空間。比如x64體系結構的CPU，就是在32位的基礎上添加了64位的操作指令，寄存器，同時提供了64位的虛擬地址空間。壹臺電腦能不能支持64位的系統，首先要看其硬件配置，即CPU是否支持64位指令：
比如我的Dell Inspiron 1420，用的是intel的芯片，支持EM64T指令集，是屬於x64架構的。這裏x64也叫x86-64，是壹個體系架構，AMD的實現稱為AMD64，而intel的實現稱為Intel64，其指令集稱為EM64T.
請點擊輸入圖片描述
操作系統
有了64位的CPU，妳才能裝64位的操作系統，當然，妳也完全可以在x64的機子上安裝32位的系統，因為其本來就是32位cpu的壹個擴展，完全支持32位指令集。
不同的64位系統有不同的編程模型(programming model)，也就是常說的那些LP64, LLP64或者ILP64等等的，之所以出項這些所謂的編程模型，目的就是為了更好的兼容以前的32位下的編程模型，繼而能讓32位的源代碼比較容易的遷移到64位（更多內容參考：64-Bit Programming Models: Why LP64?），目前Windows支持的是LLP64，而Linux/Unix支持的是LP64 - 這種編程模型的差異恐怕會給我們編寫64位可移植程序帶來壹定的困難。
應用程序
有了64位的操作系統，妳才能運行64位的應用程序。當然，妳也完全可以在64位系統下以兼容模式運行32位程序，而且因為cpu本來就支持這些32位的指令集，所以性能基本不會有影響。
為什麽需要在64位系統下使用32位程序
所以在64位的系統上，我們最好使用64位的程序，但有的情況下，我們卻不得不在64位系統下運行32位程序。
原因其實很簡單：不支持64位。
我們知道，壹個32位的程序要移植到64位上，因為壹些數據類型大小的變化（主要是指針），是需要做很多工作的，包括代碼的更新與64位下的測試，所以，壹些軟件廠商或者開發團隊會選擇不支持64位，或者想支持但無法及時推出壹個64位版本，這裏可以分為兩種情形：
程序
這種情況比較簡單，妳不支持64位，我就直接在32位兼容模式(WOW64)下跑，反正影響也不大。而且，即使妳沒做移植，同樣可以通過重新編譯而從64系統上獲取壹些好處：
However, on the x64 platform, 32-bit x86 applications may still benefit from a 64-bit?recompile, due to the additional registers in 64-bit code, which a?compiler?can use for optimization.庫
這種情況比較復雜，壹個32位的庫，比如說DLL，妳無法把他加載到妳的64位進程中，原因很簡單，類型大小不匹配。舉個最簡單的例子，我調用這個32位庫中的函數傳個指針過去，傳過去的是64位的指針，可人家以為只有32位，這不撐破了嗎？
要在64位的程序中使用32位的DLL，目前有個辦法就是通過壹個32位的進程把32位的DLL加載進來，然後通過進程間通信（RPC）。壹般情況下，這個32位進程是壹個進程外的COM組件（參考：Process Interoperability）。 當然，我們在設計COM接口的時候要註意32位-64位的接口兼容性。簡單來講，在Windows上采用的是LLP64模型，32位和64位的差別主要在於指針類型，因為是RPC，COM的marshalling就能很好的解決這個問題。
我想我們公司的軟件Autodesk Inventor就很好的說明了這個情況，大概在07年之前，Inventor是不提供64位版本的，所以在64位系統上Inventor是以32位兼容模式運行的，原因我想應該是Inventor龐大的source code使其無法迅速移植到64位之上。這是就是第壹種情況；到07年支持64位後，因為微軟提供的VBA只有32位版本的（微軟為了推VSTA而放棄了VBA的開發），我們只能提供壹個進程外COM組件通過RPC來調用VBA，所以在64位下啟動VBA速度會比較慢壹點，這就是第二種情況。
當然，這些應該都是過渡期的產物，將來的趨勢是要麽支持64位而活下來，要麽不支持64位而消亡，比如說VBA。但不可否認，這個過渡期是很漫長的。