Windows 64 位版本的C C 程式設計

microsoft_ visual c 和 microsoft_ visual c++_ .net 2002 編譯器新增了 /wp64 開關，這使您可以測試 32 位**的 64 位相容性問題。編譯器將發出有關指標截斷和不正確轉換的警告。將 32 位應用程式遷移到 windows 64 位版本中前面的乙個步驟就是開啟這個標記，然後就像通常編譯**那樣來編譯您的**。第一次會有幾個錯誤。例如，請看下面這個**片段：

dword i = 0;
size_t x = 100;
i = x; // c4267: warning c4267: '=' : conversion from 
// 'size_t' to 'dword', possible loss of data.

在 32 位的平台上，這段**能夠很好的進行編譯，因為 size_t 是 32 位的，但是在 64 位的平台上，size_t 就是 64 位的整數。啟用 /wp64 後，編譯器將會警告您類似的情況。

其他示例：

void func(dword context)
char* string = "the quick brown fox jumped over the lazy dog.";
func((dword)string); // c4311: warning c4311: 'type cast' :
// pointer truncation from 'char *' 
// to 'dword'

在修復這些錯誤後，請測試您的 32 位**。您希望確保 32 位的**繼續按預期那樣工作。32 位和 64 位二進位制檔案應該從相同的**庫中構建。這就是編寫不斷前進的 windows 應用程式的關鍵概念。開始時，您需要考慮 32 位和 64 位的問題，並且為應用程式編寫可以執行在這兩個平台上的**。

windows 64 位版本使用 llp64 資料模型。這意味著標準 c 型別 int 和 long 保持為 32 位整數。資料型別 size_t 將對映到處理器詞大小（ia32 為 32 位，ia64 為 64 位），並且 __int64 是 64 位整數。在協助遷移 32 位**時就會完成上述操作。意義在於您可以對應用程式的 32 位版本和 64 版本使用相同的**庫。

還有乙個稱為 lp64 的資料模型，它將標準的 c 型別 long 對映到 64 位整數，並使 int 保持為 32 位的整數。這種資料模型常見於 unix 平台，但從單個**庫同時建立應用程式的 32 位和 64 位版本時可能有一些困難。您可能注意到了此處的常見主題。32 位平台與 64 位平台的思想就是應該能夠從單個**庫中構建兩個版本的應用程式。如果無法做到，那麼您可能要重新審視您的設計。具有單個**庫就是巨大的勝利，尤其是如果您計畫發行兩個版本。

由於 win32 api 是針對 c 的，在很多情況下，您都需要將整數轉換成指標或者相反。在 32 位的硬體上不會有問題，其中指標的大小和整數的大小是相同的，但在 64 位的硬體上卻完全不一樣。這就是多型型別出現的原因。

對於特定的精度，您可以使用固定精度的資料型別。不管處理器的詞大小如何，它們的大小都是一致的。大多數這些型別都在它們的名稱中包含精度，可以從下面的表中看出：

表 1. 固定精度的資料型別

型別定義

dword32

32 位無符號整數

dword64

64 位無符號整數

int32

32 位有符號整數

int64

64 位有符號整數

long32

32 位有符號整數

long64

64 位有符號整數

uint32

無符號 int32

uint64

無符號 int64

ulong32

無符號 long32

ulong64

無符號 long64

此外，當您需要資料型別的精度隨著處理器詞大小變化時，請使用指標精度資料型別。這些型別又稱為「多型」資料型別。這些型別通常以 _ptr 字尾結尾，如下面的**所示：

表 2. 指標精度的資料型別

型別定義

dword_ptr

指標精度的無符號長型別

half_ptr

指標大小的一半。用於包含乙個指標和兩個小型欄位的結構中

int_ptr

指標精度的有符號整型

long_ptr

指標精度的有符號長型別

size_t

指標可以引用的最大位元組數。用於必須跨指標的整個範圍的計數

ssize_t

有符號 size_t

uhalf_ptr

無符號 half_ptr

uint_ptr

無符號 int_ptr

ulong_ptr

無符號 long_ptr

lparam

與 long_ptr 為同義詞，（在wtypes.h 中定義）

wparam

與 uint_ptr 為同義詞，（在 wtypes.h 中定義）

通過整數引數傳遞引數或上下文資訊的所有 win32 api 都更改為使用這些新的型別。setwindowlong 和 setwindowlongptr 函式都是很好的示例：

舊方法：

long setwindowlong(
hwnd hwnd, 
int nindex, 
long dwnewlong);

新的多型方法：

long_ptr setwindowlongptr(
hwnd hwnd, 
int nindex, 
long_ptr dwnewlong);

請注意，該函式的 ***ptr 版本使用新的多型型別。對於開發人員而言，通過在視窗的額外資料區域中儲存指標來儲存視窗的上下文資訊是相當常見的。使用 setwindowlong 函式在 windows 32 位版本上儲存指標的任何**必須更改為呼叫 setwindowlongptr。該更改非常簡單並且很快就可以完成，因為大多數更改要求使用多型型別。

另外，windowproc 和 getqueuedcompletionstatus 也是很好的示例：

lresult callback windowproc(
hwnd hwnd, 
uint uimsg, 
wparam wparam, 
lparam lparam);
bool getqueuedcompletionstatus(
handle hcompletionport, 
lpdword lpnumberofbytes,
pulong_ptr lpcompletionkey,
dword dwmilliseconds);

windowproc 使用 lparam，後者是多型型別。getqueuedcompletionstatus 使用 ulong_ptr，後者也是多型型別。這使那些假設整數的大小與指標大小相同的現有**可以在進行很少修改的情況下繼續工作。

包括 microsoft_ visual studio_ .net 2002 的編譯器包含兩個新的優化模式：link time code generation（ltcg，又稱 whole program optimization）和 profile guided optimization (pogo)。**優化在 itanium 處理器上比在 x86 平台上更為重要，因為編譯器對生產高效**負有全部責任。這兩種優化模式將增加構建次數，並且要求良好的測試方案，尤其是 pogo（因為它需要捕獲分析資料）。ltcg 允許鏈結器跨模組邊界執行優化，並且通過生成更好的內嵌**甚至使用自定義呼叫約定，在鏈結階段實際地生成**以產生更有效的二進位制檔案。pogo 使編譯器可以根據使用模式來進行優化。它要求兩個階段的構建過程。在第乙個階段中，二進位制檔案用於使它收集分析資料。在第二個階段中，對分析資料進行分析後，資料用於指導優化。

當前的編譯器擅長於產生高優化的**。在 itanium 處理器上，編譯器負責非常多的工作。因為 itanium 是順序處理器，編譯器必須執行優化（如重新排列指令），以便它們可以並行執行。同樣，借助於增加的謂詞暫存器，編譯器在優化分支處理上有了更多的自由。使用謂詞暫存器，編譯器可以完全去除乙個分支，並可以使用指令的謂詞欄位來控制是否實際地執行某個指令。這對於效能是有好處的，因為不在小塊的**上跳轉以及不再使指令預取無效，編譯器可以通知處理器有條件地忽略這些指令。

考慮 itanium 處理器上的校準非常重要。指標必須在 64 位邊界上校準，否則您將收到乙個校準異常。您可以使用 unaligned 關鍵字來允許未校準的指標差異，但您將為此付出巨大的效能代價。通常情況下，可以使用 #pragma pack 指令，讓編譯器處理結構的校準。這使您可以指定用於 32 位和 64 位的不同的校準（在編譯時），而不是手動校準**中的結構。

Windows 64 位版本的C C 程式設計

Windbg 32位版本和64位版本的選擇

windows 64位系統初步了解

Windows 64位系統安裝Apache2 4

Windows 64 位版本的C C 程式設計

Windbg 32位版本和64位版本的選擇

windows 64位系統初步了解

Windows 64位系統安裝Apache2 4

相關推薦