第一講 什么是64位系統
截至本課程編寫的時間為止，市場上有兩種受歡迎的64位微處理器體系結構：IA64 和Intel64
- IA-64是由 Intel 和HP 合作開發的64位微處理機體系結構。Itanium 和Itanium2 微處理機中就是用了這種體系結構。如想了解更多關於IA-64的信息，請查看Itanium。
- Intel 64 (EM64T / AMD64 / x86-64 / x64)是x86體系的繼承，同時保持向后兼容。這種體系結構的名字有不同變型，因而導致了一些疑惑，但是以下這些名字所指的都是同樣的事物：x86-64, AA-64, Hammer Architecture, AMD64, Yamhill Technology, EM64T, IA-32e, Intel 64, x64。 想了解更多為什么會有這么多不同的名字，請參看文章。
你需要了解到IA-64與Intel64是完全不同、不能相互兼容的微處理機體系結構。在本文的范圍內，我們僅討論在Windows軟件開發人員中比較受歡迎的Intel64（x64/AMD64）結構。相對應的，當我們說起Windows 操作系統的時候，我們指的對應Intel64體系的64位操作系統。例如，Windows XP Professional x64 Edition, Windows Vista x64, Windows 7 x64。 Intel64所對應的編程模型，對於基於64位windows開發的程序員來說，簡稱為Win64。
Intel 64 體系結構
以下給出的信息是基於 "AMD64 Architecture Programmer's Manual. Volume 1. Application Programming".
Intel64 體系結構，在我們看來，就是一個簡單但是非常有效的對於現有的商用x86體系結構的反向兼容。Intel64 加入了64位地址尋址的內容，同時擴展了資源來更好支持高性能的64位程序。陳舊的16位和32位的應用和操作系統，不需要進行額外的修改或者是重新編譯，就可以在64位體系結構上運行。
64位體系結構出現的原因在於應用需要更大的尋址空間。這些應用可能是高性能的服務器，數據管理系統，CAD或者游戲。這些應用將從64位地址空間和更多地寄存器中得到大量的性能提升。在陳舊的x86系統中，只有少量的寄存器存在，因而限制了計算任務的性能。寄存器數量的增加使得能夠進一步提高應用的性能。
讓我們首先來看一下x64體系的優勢。
l 64位尋址空間
l 擴展的寄存器組
l 開發者熟悉的命令集
l 可以在64位結構的操作系統上運行32位程序
l 可以直接使用32位操作系統
64位操作系統
基本上所有現在的操作系統都有支持64位體系結構的版本。 例如，Mircosoft就發布了Windows XP x64。大型的UNIX的開發者也發布了64位版，例如Linux Debian 3.5 x86-64，但是這不代表着這些系統的全部代碼是64位的。因為64位系統提供反向兼容，有些操作系統和許多應用仍然是32位。因此，64位版的Windows 使用了一個特殊的模型 WoW64 (Windows-on-Windows 64)，這個模型能夠翻譯32位應用的調用來使用64位操作系統的資源。
地址空間
雖然64位處理器理論上能夠支持16 Ebytes (2^64)的內存空間，Win64現在僅僅支持16Tbytes (2^44)的空間。造成這個現象的原因有一些：現代的處理器僅僅能夠提供1Tbyte (2^40)的物理存儲的尋址。這個體系（不是這個硬件部分）可以擴展到支持4 Pbytes (2^52)的空間，但是在這種情況下你需要大量的內存來存儲分頁表。
除了上述描述的局限以外，每一種64位Windows版本的上內存的大小取決於Mircosoft的商業決定。不同的Windows版本有不同的限制如下表所示。
表1 不同Windows版本所支持的地址空間
Win64 編程模型
與Win32類似的，Win64的頁面大小也是4 Kbyte。最靠前的64Kbyte 地址空間是不開放的，所以最低的正確的地址是0x10000。而不像在Win32中，系統的DLL占據了超過4 Gbyte的空間。
Intel64 的編譯器有一個特性：它們可以用寄存器來更有效率的傳遞參數給函數，而不是使用堆棧。這就使得使用Win64體系的開發人員可以丟棄調用約定（calling convention）的概念。在Win32中，你可以使用許多約定，比如__stdcall, __cdecl, __fastcall。在Win64種，只有一個調用約定。下面的例子，是來描述4個整型參數是怎樣通過寄存器的。
l RCX: 第一個參數
l RDX: 第二個參數
l R8: 第三個參數
l R9: 第四個參數
在第四個參數之后的參數通過堆棧來傳遞。如果是要傳遞浮點型的參數，需要使用XMM0-XMM3 寄存器和堆棧。
在調用約定方面的區別，使得開發人員不能夠在同一個程序中同時使用64位和32位的內容。用另一句話來說，如果一個應用是通過64位來編譯的，所有的動態鏈接庫也要是64位。
通過寄存器來傳遞參數，是使得64位程序比32位程序快的一個創新。你可以通過64位的數據結構來取得進一步的性能提升。在下一講中我們將討論這方面的問題。
第二講 64位Windows環境對32位應用的支持
在我們開始討論64位程序前，讓我們談論一下64位Windows系統對32位應用的反向兼容。反向兼容是通過WoW64中的機制來實現的。
WoW64 (Windows-on-Windows 64-bit) 是Windows操作系統的一個子系統，它使得能夠在64位Windows系統上執行32位應用。
WoW64子系統不支持以下程序：
- 為16位操作系統所編譯的程序
- 為32位操作系統所編譯的內核（kernel-mode）程序
間接費用
不同處理器體系的WoW64 有一些不同。例如，為Intel Itanium 2 開發的64位Windows版本，使用WoW64來模擬x86 指令。這個模擬比起Intel64 的WoW64體系需要更多資源，因為系統在執行32位程序的時候需要從64位模式轉換到兼容模式。
Intel 64 (AMD64 / x64) 上的WoW64 不需要指令模擬。在這個系統上，WoW64子系統僅僅是通過在32位應用和64位Windows API之間添加額外的一層，來模擬32位的環境。在有些地方，這新加的一層可能比較薄，在另一些地方這一層比較厚。平均來說，對於一個程序，你需要期待因為這一個層次所帶來性能上2%的損失。對於有些程序來說，這個數值可能更大。2%可能並不是一個很大的數字，但是你需要銘記在心的是32位程序在64位系統中比它們在32位系統中運行的要慢。
把程序編譯為64位的代碼，不僅使你避免使用WoW64，同時能使你得到了性能上提升。這個可以通過體系結構上的改變，如更多的通用寄存器來解釋。平均來說，對於一個程序，通過簡單的重新編譯，你可以期待着在性能上有5%-15%的提升。
在64位環境上運行32位程序的好處
因為WoW64，32位程序在64位系統中比它們在32位系統中運行的要慢。但是簡單的32位程序可以從在64位系統上執行獲得一個好處。或許你知道，如果在32位Windows系統選擇“/3gb”, 程序編譯時選擇"/LARGEADDRESSAWARE:YES"，它可以分配到最高達3 Gbytes的內存空間。同樣的32位程序在64位系統可以分配大最高達4Gbytes的內存空間（現實中大約是3.5 Gbytes的內存空間）。
重定位
WoW64子系統是通過將調用重定位至文件和寄存器， 從而將32位程序與64位程序分離開來。 這樣使得32位程序不會意外的接觸64程序的數據。例如，一個從"%systemroot%\System32"中調用了DLL文件的32位應用程序，如果不進行隔離，那么它可能調用了一個32位程序無法兼容的64位DLL文件。為了避免這樣的情況發生，WoW64位子系統將進入"%systemroot%\System32"文件夾的調用重定位到調用"%systemroot%\SysWOW64"文件夾中的文件。這種重定位使得開發者能避免兼容性的問題，因為32位應用程序需要能與它們兼容的特殊的DLL文件。
如想了解更多關於文件系統或寄存器的重定位，可以參考MSDN相關章節"Running 32-bit Applications"。
為什么32位DLL不能在64位程序中使用？ 是否有方式可以避免這種局限？
現在是不能夠在64位進程中調用32位DLL並執行它的代碼。這種不可行是因為64位系統的設計造成的。所以說是從根本上的不可能。沒有任何技術，也沒有任何文檔沒有記錄的方式可以幫助到你。為了做到這個，你必須要裝載並初始化WoW64，更不用說內核結構的不同了。這代表着64位的處理器必須在運行中被處理為32位。這個話題在"Why can't you thunk between 32-bit and 64-bit Windows?". 中有更為詳盡的描述。有一件事情是我建議可以嘗試的，就是建立一個使用COM技術創建一個替代程序， 你可以閱讀"Accessing 32-bit DLLs from 64-bit code".
但是，從32位DLL 將資源導入到64位進程中去，是比較容易的，你所需要的就是在調用LoadLibraryEx 的時候制定以下的flag：LOAD_LIBRARY_AS_DATAFILE。
逐漸放棄對32位程序的支持
微軟公司為了進一步促進程序向64位遷移，會逐漸在一些版本的Windows操作系統中取消對32位程序的支持。這是一個自然的過程。當然這個過程會比較緩慢，但這個行為已經開始了。
許多管理員可能會知道一個較新的操作系統上的服務器安裝和操作模式，叫做Server Core。 這個模塊正是在持久的“Windows VS Linux”大戰中被廣泛提起。 其中一個支持使用Linux的原因就是Linux支持不需要圖像接口就可以安裝服務器操作。 但是，現在Windows Server
也有了這種能力。如果你在這種模式中安裝系統，你將只獲得系統的命令行，而不需要用戶界面。
這種能力（Server Core安裝）出現在Windows Server 2008. 但是在 Windows Server 2008 R2 中，另外一種創新出現使得系統更接近64位。在Windows Server 2008 R2 (Server Core )中，你可以啟動或者禁用系統對32位應用程序的支持。 更重要的是對32位應用程序的支持默認是被禁用的。所以當你嘗試在Server Core mode中啟動32位程序的時候，你會得到一條系統消息告訴你，這是不可以的。如果你需要額外手動啟用這種支持，可以通過以下命令實現：
start /w ocsetup ServerCore-WOW64
在普通的模式（完全安裝），執行32位程序的支持默認是啟用的。
這種趨勢是十分明顯的，因而現在開始創建64位版本的應用是理智的，因為64位的程序能保證在更多的操作系統版本上使用。
額外信息
Alexey Pahunov的 Russian blog 也是獲取WoW64資料的好地方。Alexey是Microsoft 的員工，他參與了WoW64子系統的開發。
第三講 將代碼導入64位系統的優缺點
你需要帶着以下的問題來學習64位系統：“ 往64位系統重新編譯項目的合理性有多少？”回答這個問題，你需要花費一些時間和精力來思考。在一方面，你可能會因為要提供64位系統的應用支持，使得你在市場上落后於你的對手。 在另一方面，你可能會花費了時間在開發64位系統應用上，而這一努力並不能給你帶來競爭優勢。
以下是一些建議可以用來幫助你做出選擇。
應用的生命期
當你的應用有一個比較短的生命期，你暫時還沒有必要開發應用的64位版本。WoW64子系統使得陳舊的32位應用在64位機上也能取得比較好的表現。如果你在兩年內會停止運營你的產品，你是不需要現在建立一個64位版本的。實踐證明向64位系統的遷移是一個非常緩慢平和的過程。可能你的大多數用戶在未來的一段時間里還是會僅僅使用你系統的32位版本。你需要知道，本教程是在2009年編寫的，這時候大部分用戶都還是在使用32位系統。但是很快32位程序，就會變得越來越不自然，會變得落伍的。
如果你的項目有一比較長的開發和維護時間，你需要開始建立你產品的64位版本。當然你可以慢慢來，但是你要記住的是，越遲擁有產品的64位版本，在64位系統上維護32 位版本所帶來的問題將越來越多。
程序性能要求
當一個程序重新編譯以適應64位版本后，程序可以應用大量的內存資源，它的速度將提高5%-15%。5%-10%的系統提升是因為64位體系結構的特點，如更多的寄存器，所導致的。另外的1%-5%的性能提升是因為拋棄了翻譯32位應用使之在64位系統環境運行的WoW64層所帶來。
例如，Adobe公司稱新版本64位的"Photoshop CS4"比32位版本的快了12%。
需要大量的內存的應用可以期待着有更高的性能提升。比如說，圖像編輯器，CAD系統，GSI CAD，數據庫和其他的模型包。能將所有的數據存儲在內存中，而避免了多余的從硬盤中導入的工作，使得這些應用的速度，可能不是提升了幾個百分點，而是成倍的提高。
例如，Alfa-Bank 曾經在他們的IT 基礎設施中使用了基於Itanium 2的平台。原因在於他們業務的發展使得現有系統無法支持不斷增長的數據量。每個用戶的服務延遲變得非常嚴重。分析顯示，系統的瓶頸不在於處理器的表現，而在於32位體系結構與內存子系統的關系上，因為32位體系結構使得只能使用4 Gbyte的服務器地址空間。而它們的數據庫卻大於9 Gbyte。因而導致了子系統的輸入輸出的臨界負荷。Alfa-Bank決定購買一個由2個服務器組成的集群。這兩個服務器都擁有4處理器、是基於Itanium 2的、擁有12Gbyte內存的。 這個決定使得他們的性能要求達到了可以容忍的程度。這個公司的代表稱，引入基於Itanium2 的服務器使得他們解決了重要問題，同時也節約了花費。
在項目中使用第三方庫
在決定是否開發你產品的64位版本前，請先確認你所依賴的第三方庫是否有64位版本。你需要找出第三方軟件64位版本的定價是多少。這些你都可以在庫開發者的網站上找到。如果，沒有依賴庫的64位版本的支持，可以尋找其他支持64位的庫作為替代。
你所開發的庫的第三方開發者
如果你在開發庫，組件，或者其他需要給第三方開發者使用的程序時，你需要盡快的開發一個你的庫的64位版本。否則需要64位支持的你的客戶會轉向其它的替代產品。例如，一些軟件和硬件安全方面的開發者，都非常遲的開發64位版本，使得他們的一些客戶轉向了其他工具來保護自己的產品。
發布你所開發庫的64位版本有另一個好處， 你可以把它作為一個單獨模塊來出售。因而想要開發32 位和64位的客戶會要購買2個不同的授權。例如Spatial Corporation，就是按這個方式來賣他們的Spatial ACIS庫的。
16位應用
如果你的應用仍然有16位的模塊， 你需要丟棄它們。64位的Windows版本完全不支持16位的應用。
關於使用16位安裝程序的人員，我需要解釋一個事情。這樣的安裝程序仍然在被使用於安裝一些32位應用程序。因為對於一些比較流行的16位的安裝程序，它們之中包含了一些機制，使得它們能夠在運行中被更新的32位安裝程序。這可能使得你覺得16位的程序，在64位的系統環境中仍能使用，但這是錯誤的，請牢記。
匯編器代碼
不要忘記了，大量的匯編器代碼片是使得創建應用的64位版本更為困難的原因之一。
工具箱
如果考慮以上提到各種因素后，你決定創建一個你的應用的64位版本，成功不是一定的。你還需要一些必要的工具，以下就是一些你可能會碰到的不愉快的事情。
首先最令人不開心的事情，就是缺少64位的編譯器。當我們寫本教程的時候（2009），Embarcadero還沒有64位C++編譯器，它有期望在2009年年底發布一個。除非你重新編寫你自己的部署部分，如使用Microsoft Visual Studio時可以快速改變配置，否者你沒有辦法回避這個問題。但其他的問題，就沒有像缺少編譯器這樣，容易被察覺，可能會在你將程序導入一個新的體系結構的時候發生。你可以在開始工作前，做一個調研，看所有需要的組件是否都有64位版本可以使用。不然，你將面臨不愉快的事情。
做決定時，還需要注意到一個我們還沒提到的問題，修改你的代碼使之可以在64位模式下編譯所需要的花銷。我們會在之后的課程里，告訴你怎樣估計這個花銷。這個花銷可能是非常高昂的，需要經過系統的計划和詳細的時間安排。