可訪問大地址的應用 (Large-Address-Aware Executables)

在Windows增加支持/3GB參數以前,一個應用程序是無法訪問一個帶有高位設置的指針.一個32位的指針只有前31位地址空間可以被用戶模式的應用程序訪問.這剩余的一位不用.因此有一些聰明的開發者因為其他的目的不愿意在處理內存地址空間時浪費這一位.(舉例來說:可以用來標志一個指針引用其它應用程序分配的數據類型).這樣就/3GB參數就遇到一個難題,因為這種類型的程序不能方便的區分一個合法的指針引用的內存空間在2G的分界線以上與一個內存地址空間在2G以下,但它的高位已經被用做它用的指針.基本上如果一臺機器用/3GB的參數啟動,這種應用程序是無法運行的.為解決這種狀況,微軟在WIN32的PE文件Characteristics字段增加了一個新的標志位來表示一個程序是否運行在可訪問大地址的(Large-Address-Aware Executables)模式.當該標志位被起用( IMAGE_FILE_LARGE_ADDRESS_AWARE ),該可執行文件頭部Characteristics字段的32位被置位.通過這個可執行文件頭部的標志位,應用程序可以暗示WINDOWS 它可以處理帶有高位設置的指針,這樣就不會帶來任何異常結果.當該標志被置位并且支持這種方式啟動的Windows也是通過/3GB的參數啟動,這時操作系統會提供一直擴展的私有用戶模式的地址空間給應用程序.你可以通過工具,比如: DumpBin 和 ImageCfg (轉儲可執行文件的頭部)來檢查一個可執行文件的該標志位.Visual C++ 通過 /LARGEADDRESSAWARE 連接器開關來表示IMAGE_FILE_LARGE_ADDRESS_AWARE，SQL SERVR已經將該標志位激活,所以你可以在支持/3GB參數的Windows 版本中使用該參數,這樣操作系統回自動擴展SQL SERVER的用戶內存空間.

注釋:Windows在可執行文件啟動時檢查IMAGE_FILE_LARGE_ADDRESS_AWARE 標志位,但忽略DLL文件.DLL代碼必須自動處理高位被置位的指針。

 物理內存擴展

    Intel 處理器自從Pentium PRO開始，以后的處理器都支持一種物理內存擴展（PAE）的內存映射模式。PAE模式提供了可以訪問64GB的物理內存空間。在PAE模式中，內存管理單元（Memory Management Unit (MMU))仍然執行：頁目錄入口page directory entries(PDEs) 和頁表入口page table entries (PTEs),但是在此之上有一個新的級別：頁目錄指針表。同時，在PAE模式PDEs 和PTEs是64位的（不僅僅是標準的32位），這樣系統可以映射比標準轉換更多的內存空間，因為PDEs 和PTEs模式的尋址寬度是標準的2倍。這并不僅僅是增加了頁目錄指針表。頁目錄指針表被用來管理這些大容量表和索引。一些特殊版本的Windows內核需要運行在PAE模式。這中內核集成在Windows 2000以及以后的版本中，在單處理器的機器中體現在Ntkrnlpa.exe文件中，在多處理器的機器中體現在Ntkrnlpamp.exe文件中。你可以向增加/3GB和/USERVA參數一樣在BOOT.INI文件中加/PAE參數激活PAE模式。

 地址窗口擴展

Windows的地址窗口擴展（AWE）機制可以允許應用程序訪問超過4GB的物理內存。一個32位的指針是一個整數，只能保存0x00000000到0xFFFFFFFF的值，就是說可以引用4GB 以內線性的內存地址空間，AWE允許一個應用程序繞過這些限制，通過操作系統訪問所有的內存空間。

從概念上說，AWE并不是一個新的事物。在計算機發展之初，操作系統和應用程序已經使用相似的機制回避指針的限制。例如：我們倒退到DOS年代，32位擴充功能被經常用來允許一個16位的程序訪問他自已以外的內存地址空間。一些特殊目的管理者和API經常使用擴充內存和擴展內存。你可能記得這樣一個很久以前產品Quarterdeck QEMM-386經常用來做這樣的事情。典型的機制是允許一個指針可以訪問超過本身限制的空間，（比如：地址太大無法在自己的指針中）通過在可以訪問的地址空間分配一個窗口或區域來和本身無法訪問的內存地址之間傳遞指針。AWE的工作原理：你可以在可以訪問的地址空間提供一塊區域（窗口）作為分段傳輸區，來傳送在用戶內存空間無法訪問的內存地址。

為了使用AWE，一個應用程序需要：

1．分配的物理內存地址可以通過AllocateUserPhysicalPages  API函數訪問。這個函數需要調用者有Lock Pages in Memory的權限。

2．在可以訪問的內存空間建立一塊區域。通過VirtualAlloc API函數可以作為映射一個物理內存的映射窗口。

3．通過MapUserPhysicalPages 或MapUserPhysicalPagesScatter WIN32 API 函數完成物理內存和虛擬內存的映射。

AWE已經存在于所有的Windows 2000和以后的操作系統中,甚至可以用于物理內存低于2GB的操作系統中，最典型的應用是在2GB或以上物理內存的機器上，因為這是一個32位處理器訪問3GB以下內存空間的唯一方法。如果你在一個低于3GB物理內存的SQL Server系統中激活AWE支持，系統將忽略這個選項同時轉換為虛擬內存管理器代替。AWE內存有一個有趣的特征就是從不和磁盤交換數據。你也許注意到特有的AWE API程序引用可以訪問的內存空間是作為物理內存訪問。這點確切的說就是：AWE內存是不和系統的虛擬頁面文件交互物理內存空間。

虛擬內存窗口被用來緩存AWE讀寫訪問物理內存的請求。因此，當你配置這個窗口是PAGE_READWRITE唯一可以保護的特征就是轉嫁給了VirtualAlloc API函數。不要驚奇，這也意味你不能用VirtualProtect API函數來保護這塊內存區域的修改和訪問。

注釋:還沒有專門的工具用來調查應用程序AWE內存使用（任務管理器，性能監視器和監視系統 等等），顯示每一個程序AWE內存的使用數量。這樣就沒有每個程序使用AWE內存數量的軌跡，同時這些內存也沒包括在每個的程序的工作內存集中。

 /3GB 和AWE比較

     增加用戶程序地址空間的能力幾乎有50％的應用程序是通過內存調整，這是在Windows內存管理機制當中非常快捷和受歡迎的手段。而且Windows AWE內存機制也是非常靈活和穩定的。就像我前面所說的，當你增加1G的用戶內存空間，這些內存是通過減少核心內存空間獲得的（從2G減到1G）。因為核心代碼的運行對整個內存空間來說是很狹窄的一塊即使用于2G的空間，收縮這些內存空間意味著內部核心架構也會收縮。其中最重要的是windows用來管理物理內存的表,當你收縮核心內存空間到1G，你就限制了這個表的大小，這樣只能管理最大16GB的物理內存。例如：如果你的應用程序運行在有64GB物理內存的SERVER上并且你在啟動時加了/3GB的參數。你只能訪問整個內存的25%的空間—其余的48GB的內存空間無論時操作系統還是應用程序都無法訪問。AWE可以允許你訪問比加/3GB參數更高的內存空間。顯然，你通過/3GB的參數只是增加了1GB的用戶內存空間，這些增加的內存空間只是對那些大地址自動獲得的應用程序有效，但是只有1GB。和/3GB參數對比，AWE可以使整個的物理內存對操作系統有效和對使用AWE WIN32 API的應用程序有效。因此，AWE使用和操作起來更加復雜，也更加靈活和可擴展。

   著并不是說/3GB比AWE更好是不存在的－不過這確實存在，比如：如果你需要分配更多的內存空間，但不能在AWE中分配（線程堆棧，內存鎖，過程計劃），你也許發現/3GB回更好一些。