x64位windows上程式開發的注意事項

轉自：http://hi.baidu.com/cshacker/blog/item/bd13fff989cf8950242df268.html

加 http://school.cnd8.com/windows-xp/jiaocheng/38341.htm

在Windows上面32位與64位的區別有：

1.指標大小的區別，sizeof(int *)在32bit下面是4個位元組，在64bit下面是8個位元組
2.size_t的區別，size_t在32bit下面是4個位元組的範圍，在64bit下面是8個位元組的範圍
3.地址空間的區別，在32bit下面，最大地址空間是4GB，在64bit下面是可以大於4GB的
4.32位程式在64位Windows上運行，是有一個Wow64子系統輔助其啟動並執行，預設情況下，訪問註冊表和某些檔案夾是被重新導向的
5.指標的區別也意味著Handle的區別
6.唯一支援Windows原始64位編譯的msvc編譯器不支援64bit的內聯彙編，如果要用彙編，需要單獨編譯再link
7.純64bit程式的函數調用方式已經不再區分cdecl和stdcall方式，因為只有一種了。
8.64bit的程式不再使用esp，而是使用增加的幾個64bit寄存器，因為esp不支援64bit空間的棧

最近的工作涉及到Linux的64位工作，發現當初對32位和64位區別的認識還不夠：
1.long在Windows下面，不管是32bit還是64bit下，都是4個位元組的，但在Linux下面，32bit下是4位元組，在64bit下是8個位元組。(long long在64bit下還是8個位元組)
2.gcc在64bit下面，不再支援__attribute((cdecl))__和__attribute((stdcall))__，這點和Windows有點類似，開始以為是gcc的高版本不支援的，後來發現區別在x86和x64

64位下windows的開發建議：

1.避免System.BadImageFormatException

　　通常，程式員碰到這種情況：“出現未處理的類型異常 ‘System.BadImageFormatException’”。如果你要深究該異常的細節資訊，可能會發現系統提示：“試圖載入的程式，格式不正確”。

　　之所以會出現這樣的問題是因為64位進程試圖載入一個32位組件。雖然你在Windows x64上可以運行64位和32位進程，但是64位代碼和32位代碼不能在相同進程上運行。你的代碼要麼全部是64位，要麼全部是32位。要載入的組件也要符合這一規律。

　　VS 2005與.NET 2.0為編譯.NET應用程式帶來選擇，將輸入設定為“Any CPU”也具備了可選性。“Any CPU”是預設平台。如果組件以Any CPU作為平台進行編譯，那麼它將依據進程載入的情況以32位或64位方式運行。使用Any CPU，相同的組件可以在64位Windows上以32位或64位方式運行：它不是真正的指定了64位的CPU或作業系統，而是一個調用進程。

　　為瞭解決不合格映像異常的問題，要改變到Any CPU的所有組件的目標平台。如果出於某種原因你無法做到這一點——或許某組件無法提供來源——那麼要將所有組件設定成到達同一平台，可以是x86也可以 是x64。如果你擁有.NET 1.0或1.1組件，最好是用.NET 2.0對其重新進行編譯。如果你不能編譯.NET 1.0或1.1組件，那麼編譯其他代碼，設定為到達x86平台，使之相容。

 2.大小問題

　　64位和32位Windows之間一個重要的區別是控制代碼的大小。如果你的代碼中具備任意Windows API調用，那麼你要確保你的說明對於64位Windows是正確的。如果代碼是從VB6升級而來，那麼你不能區分控制代碼和32位整數的概念，因此你必須尋 找源檔案或標題檔案。識別哪些參數和域是控制代碼，使用這些類型的IntPtr。通常情況下，檔案將以INT_PTR或LONG_PTR將其識別或者用名稱只 是某類控制代碼，如HWND。用首碼定義的參數，如PTR或LPTR通常是一些指標，因此需被視為IntPtr或使用ByRef編組。要確定你啟動並執行64位 還是32位，可以在運行時檢查IntPtr.Size的值。

3.COM可以是64位

　　普遍存在的誤解是認為COM和ActiveX僅限於32位，但是使用VB.NET，你可以使用64位COM和ActiveX控制項。 Windows沒有按照64位編譯的控制項，但是其中一個值得注意的例外是sysmon.ocx ActiveX 控制項，該控制項可以讓你建立系統監測圖。

　　你可以使用Windows.Forms應用程式中的64位ActiveX控制項，但是當涉及彙編的時候就存在緩衝。VS當前是32位的應用程式， 它在彙編的時候需要32位的ActiveX控制項以便建立運行時可隨時啟用的COM組件封裝。為了在VS中進行編譯，你需要32位的版本。一旦程式被編譯， 就只需要被選中的平台。

　　在你沒有32位版本或類似版本的情況下，你可以使用命令列來運行64位工具以便建立一個用於ActiveX控制項的Interop程式集。見Tlblmp.exe檔案以瞭解詳情。

4.意識到問題

　　32位應用程式運行於Windows 64中時，它與模擬器一起運行。模擬器被稱為WOW64，是Windows On Windows64的縮寫，可以讓32位應用程式按照32位作業系統進行查看。WOW64模擬器載入了一個ntdll.dll的x86版本，提供了切入點 和替換程式，還會截取最重要的註冊表和檔案系統操作。

　　WOW64模擬器也暴露出不同的適合32位應用程式的環境型變數。因此，32位應用程式將ProgramFiles環境型變數為 ProgramFiles(x86)。以64位啟動並執行時候，如果你寫出類似MsgBox(Environ(“ProgramFiles”))的代碼，會獲 得"C:\Program Files"，如果你32位運行，則獲得"C:\Program Files (x86)"。

　　模擬器所做的事情與註冊表和系統目錄類似。出於相容性和效能的考慮，%windir%\System32 檔案夾是64位檔案夾。也就是說，64位應用程式中不存在任何截取。重新定向的32位操作檔案夾預設名為%windir%\SysWOW64。名稱 SysWOW64指明它要被32位模擬器WOW64使用。這或許有些令人困惑。

　　WOW64之下的註冊表將重新導向與反射結合使用。重新導向存在於HKEY_LOCAL_MACHINE\SOFTWARE \Wow6432Node等Key之下。至少註冊表中的命名式樣更好。映射是32位進程和64位進程都可以編輯共同Key，如檔案關聯。另一方面講，重定 向是為了確保將32位從64位隔離開。

　　關鍵是執行不能影響你除非你打算從64位程式中擷取32位程式的詳細資料，反之亦然。通常彙編到同一目標要簡單得多。例如，如果你想使用VS， 將程式鎖定到x86，你不需要擔心檔案或註冊表的類比過程。如果你要以Any CPU運行程式，那麼就取決於它是如何啟動的，或許你要使用重新導向，和類似GetSystemWow64Directory的API調用，並且使用 RegOpenKeyEx API，包括KEY_WOW64_32KEY的訪問假象。它可能變成混亂而複雜的測試。這是目前為止對相同平台和鎖定資訊最好的彙編方式。

　　其中筆者偶然發現的一個問題是註冊表反射和Windows Vista UAC的結合。在用於寫入許可的HKLM蜂巢中筆者開放了一個Key，API成功了，但是當筆者向Key寫入時，卻失敗了。應用程式以32位方式運行於 Windows 64上，因此有問題的Key會被映射。筆者浪費了大量時間用於確定所發生的事情，因為註冊表API不會嚮往常一樣運作。最後，筆者通過往應用程式中包含運 載單使之正常運行。即便requestedExecutionLevel對asInvoker有層級設定，這一漏洞也可以被修複。

　　UAC提供了註冊表虛擬化，筆者認為WOW64重新導向或反射與UAC虛擬化的結合太多了。現在筆者通常會確保應用程式中具備運載單。在VS 2008中，你可以從項目屬性對話方塊中的程式標籤中擷取運載單。確保你包含了requestedExecutionLevel選項。

5.啟用Edit和Continue

　　雖然，你可以調試64位應用程式，那麼就不能在調試期間使用Edit和Continue。這意味著你不能在調試的時候改變原始碼，相反你要停 止，應用更改，重新編譯並啟動調試。但是你可以用32位程式使用Edit和Continue，即便是在64位Windows上。這是另一種手動構建配置的 樣本。

　　建立一個x86構建配置，並且在開發的時候使用這一配置，如此你就可以使用Edit和Continue。然後將配置切換稱x64或Any CPU用於測試。

　　使用Windows 32或Windows 64不如VB 8或VB 9中那樣難。使用VS並且構建配置，任務會變得簡單。