我 在自己最近的編程中注意到一個趨勢，正是這個趨勢才引出本月的專欄主題。最近，我在基于 Microsoft® .NET
Framework 的應(yīng)用程序中完成了大量的 Win32® Interop。我并不是要說我的應(yīng)用程序充滿了自定義的 interop
代碼，但有時我會在 .NET Framework 類庫中碰到一些次要但又繁絮、不充分的內(nèi)容，通過調(diào)用該 Windows®
API，可以快速減少這樣的麻煩。
因此我認為，.NET Framework 1.0 或 1.1 版類庫中存在任何 Windows 所沒有的功能限制都不足為怪。畢竟，32
位的 Windows（不管何種版本）是一個成熟的操作系統(tǒng)，為廣大客戶服務(wù)了十多年。相比之下，.NET Framework 卻是一個新事物。
隨著越來越多的開發(fā)人員將生產(chǎn)應(yīng)用程序轉(zhuǎn)到托管代碼，開發(fā)人員更頻繁地研究底層操作系統(tǒng)以圖找出一些關(guān)鍵功能顯得很自然 — 至少目前是如此。
值得慶幸的是，公共語言運行庫 (CLR) 的 interop 功能（稱為平臺調(diào)用
(P/Invoke)）非常完善。在本專欄中，我將重點介紹如何實際使用 P/Invoke 來調(diào)用 Windows API 函數(shù)。當(dāng)指 CLR 的
COM Interop 功能時，P/Invoke 當(dāng)作名詞使用；當(dāng)指該功能的使用時，則將其當(dāng)作動詞使用。我并不打算直接介紹 COM
Interop，因為它比 P/Invoke 具有更好的可訪問性，卻更加復(fù)雜，這有點自相矛盾，這使得將 COM Interop
作為專欄主題來討論不太簡明扼要。
走進 P/Invoke
首先從考察一個簡單的 P/Invoke 示例開始。讓我們看一看如何調(diào)用 Win32 MessageBeep 函數(shù)，它的非托管聲明如以下代碼所示：
BOOL MessageBeep(
UINT uType // beep type
);
為了調(diào)用 MessageBeep，您需要在 C# 中將以下代碼添加到一個類或結(jié)構(gòu)定義中：
[DllImport("User32.dll")]
static extern Boolean MessageBeep(UInt32 beepType);
令人驚訝的是，只需要這段代碼就可以使托管代碼調(diào)用非托管的 MessageBeep
API。它不是一個方法調(diào)用，而是一個外部方法定義。（另外，它接近于一個來自 C 而 C#
允許的直接端口，因此以它為起點來介紹一些概念是有幫助的。）來自托管代碼的可能調(diào)用如下所示：
MessageBeep(0);
請注意，現(xiàn)在 MessageBeep 方法被聲明為 static。這是 P/Invoke 方法所要求的，因為在該 Windows API
中沒有一致的實例概念。接下來，還要注意該方法被標(biāo)記為 extern。這是提示編譯器該方法是通過一個從 DLL
導(dǎo)出的函數(shù)實現(xiàn)的，因此不需要提供方法體。
說到缺少方法體，您是否注意到 MessageBeep 聲明并沒有包含一個方法體？與大多數(shù)算法由中間語言 (IL)
指令組成的托管方法不同，P/Invoke 方法只是元數(shù)據(jù)，實時 (JIT) 編譯器在運行時通過它將托管代碼與非托管的 DLL
函數(shù)連接起來。執(zhí)行這種到非托管世界的連接所需的一個重要信息就是導(dǎo)出非托管方法的 DLL 的名稱。這一信息是由 MessageBeep
方法聲明之前的 DllImport 自定義屬性提供的。在本例中，可以看到，MessageBeep 非托管 API 是由 Windows 中的
User32.dll 導(dǎo)出的。
到現(xiàn)在為止，關(guān)于調(diào)用 MessageBeep 就剩兩個話題沒有介紹，請回顧一下，調(diào)用的代碼與以下所示代碼片段非常相似：
[DllImport("User32.dll")]
static extern Boolean MessageBeep(UInt32 beepType);
最后這兩個話題是與數(shù)據(jù)封送處理 (data marshaling) 和從托管代碼到非托管函數(shù)的實際方法調(diào)用有關(guān)的話題。調(diào)用非托管
MessageBeep 函數(shù)可以由找到作用域內(nèi)的extern MessageBeep
聲明的任何托管代碼執(zhí)行。該調(diào)用類似于任何其他對靜態(tài)方法的調(diào)用。它與其他任何托管方法調(diào)用的共同之處在于帶來了數(shù)據(jù)封送處理的需要。
C# 的規(guī)則之一是它的調(diào)用語法只能訪問 CLR 數(shù)據(jù)類型，例如 System.UInt32 和 System.Boolean。C#
顯然不識別 Windows API 中使用的基于 C 的數(shù)據(jù)類型（例如 UINT 和 BOOL），這些類型只是 C
語言類型的類型定義而已。所以當(dāng) Windows API 函數(shù) MessageBeep 按以下方式編寫時
BOOL MessageBeep( UINT uType )
外部方法就必須使用 CLR 類型來定義，如您在前面的代碼片段中所看到的。需要使用與基礎(chǔ) API 函數(shù)類型不同但與之兼容的 CLR 類型是 P/Invoke 較難使用的一個方面。因此，在本專欄的后面我將用完整的章節(jié)來介紹數(shù)據(jù)封送處理。
樣式
在 C# 中對 Windows API 進行 P/Invoke 調(diào)用是很簡單的。但如果類庫拒絕使您的應(yīng)用程序發(fā)出嘟聲，應(yīng)該想方設(shè)法調(diào)用 Windows 使它進行這項工作，是嗎？
是的。但是與選擇的方法有關(guān)，而且關(guān)系甚大！通常，如果類庫提供某種途徑來實現(xiàn)您的意圖，則最好使用 API 而不要直接調(diào)用非托管代碼，因為
CLR 類型和 Win32 之間在樣式上有很大的不同。我可以將關(guān)于這個問題的建議歸結(jié)為一句話。當(dāng)您進行 P/Invoke
時，不要使應(yīng)用程序邏輯直接屬于任何外部方法或其中的構(gòu)件。如果您遵循這個小規(guī)則，從長遠看經(jīng)常會省去許多的麻煩。
圖 1 中的代碼顯示了我所討論的 MessageBeep 外部方法的最少附加代碼。圖 1
中并沒有任何顯著的變化，而只是對無包裝的外部方法進行一些普通的改進，這可以使工作更加輕松一些。從頂部開始，您會注意到一個名為 Sound
的完整類型，它專用于 MessageBeep。如果我需要使用 Windows API 函數(shù) PlaySound
來添加對播放波形的支持，則可以重用 Sound
類型。然而，我不會因公開單個公共靜態(tài)方法的類型而生氣。畢竟這只是應(yīng)用程序代碼而已。還應(yīng)該注意到，Sound
是密封的，并定義了一個空的私有構(gòu)造函數(shù)。這些只是一些細節(jié)，目的是使用戶不會錯誤地從 Sound 派生類或者創(chuàng)建它的實例。
圖 1 中的代碼的下一個特征是，P/Invoke 出現(xiàn)位置的實際外部方法是 Sound 的私有方法。這個方法只是由公共
MessageBeep 方法間接公開，后者接受 BeepTypes
類型的參數(shù)。這個間接的額外層是一個很關(guān)鍵的細節(jié)，它提供了以下好處。首先，應(yīng)該在類庫中引入一個未來的 beep 托管方法，可以重復(fù)地通過公共
MessageBeep 方法來使用托管 API，而不必更改應(yīng)用程序中的其余代碼。
該包裝方法的第二個好處是：當(dāng)您進行 P/Invoke 調(diào)用時，您放棄了免受訪問沖突和其他低級破壞的權(quán)利，這通常是由 CLR
提供的。緩沖方法可以保護您的應(yīng)用程序的其余部分免受訪問沖突及類似問題的影響（即使它不做任何事而只是傳遞參數(shù)）。該緩沖方法將由 P/Invoke
調(diào)用引入的任何潛在的錯誤本地化。
將私有外部方法隱藏在公共包裝后面的第三同時也是最后的一個好處是，提供了向該方法添加一些最小的 CLR 樣式的機會。例如，在圖 1
中，我將 Windows API 函數(shù)返回的 Boolean 失敗轉(zhuǎn)換成更像 CLR 的異常。我還定義了一個名為 BeepTypes
的枚舉類型，它的成員對應(yīng)于同該 Windows API 一起使用的定義值。由于 C#
不支持定義，因此可以使用托管枚舉類型來避免幻數(shù)向整個應(yīng)用程序代碼擴散。
包裝方法的最后一個好處對于簡單的 Windows API 函數(shù)（如
MessageBeep）誠然是微不足道的。但是當(dāng)您開始調(diào)用更復(fù)雜的非托管函數(shù)時，您會發(fā)現(xiàn)，手動將 Windows API 樣式轉(zhuǎn)換成對 CLR
更加友好的方法所帶來的好處會越來越多。越是打算在整個應(yīng)用程序中重用 interop
功能，越是應(yīng)該認真地考慮包裝的設(shè)計。同時我認為，在非面向?qū)ο蟮撵o態(tài)包裝方法中使用對 CLR 友好的參數(shù)也并非不可以。
DLL Import 屬性
現(xiàn)在是更深入地進行探討的時候了。在對托管代碼進行 P/Invoke 調(diào)用時，DllImportAttribute
類型扮演著重要的角色。DllImportAttribute 的主要作用是給 CLR 指示哪個 DLL 導(dǎo)出您想要調(diào)用的函數(shù)。相關(guān) DLL
的名稱被作為一個構(gòu)造函數(shù)參數(shù)傳遞給 DllImportAttribute。
如果您無法肯定哪個 DLL 定義了您要使用的 Windows API 函數(shù)，Platform SDK 文檔將為您提供最好的幫助資源。在
Windows API 函數(shù)主題文字臨近結(jié)尾的位置，SDK 文檔指定了 C 應(yīng)用程序要使用該函數(shù)必須鏈接的 .lib
文件。在幾乎所有的情況下，該 .lib 文件具有與定義該函數(shù)的系統(tǒng) DLL 文件相同的名稱。例如，如果該函數(shù)需要 C 應(yīng)用程序鏈接到
Kernel32.lib，則該函數(shù)就定義在 Kernel32.dll 中。您可以在 MessageBeep 中找到有關(guān) MessageBeep
的 Platform SDK 文檔主題。在該主題結(jié)尾處，您會注意到它指出庫文件是 User32.lib；這表明 MessageBeep 是從
User32.dll 中導(dǎo)出的。
可選的 DllImportAttribute 屬性
除了指出宿主 DLL 外，DllImportAttribute 還包含了一些可選屬性，其中四個特別有趣：EntryPoint、CharSet、SetLastError 和 CallingConvention。
EntryPoint 在不希望外部托管方法具有與 DLL 導(dǎo)出相同的名稱的情況下，可以設(shè)置該屬性來指示導(dǎo)出的 DLL
函數(shù)的入口點名稱。當(dāng)您定義兩個調(diào)用相同非托管函數(shù)的外部方法時，這特別有用。另外，在 Windows 中還可以通過它們的序號值綁定到導(dǎo)出的
DLL 函數(shù)。如果您需要這樣做，則諸如“#1”或“#129”的 EntryPoint 值指示 DLL 中非托管函數(shù)的序號值而不是函數(shù)名。
CharSet 對于字符集，并非所有版本的 Windows 都是同樣創(chuàng)建的。Windows 9x 系列產(chǎn)品缺少重要的 Unicode
支持，而 Windows NT 和 Windows CE 系列則一開始就使用 Unicode。在這些操作系統(tǒng)上運行的 CLR 將Unicode
用于 String 和 Char 數(shù)據(jù)的內(nèi)部表示。但也不必擔(dān)心 — 當(dāng)調(diào)用 Windows 9x API 函數(shù)時，CLR
會自動進行必要的轉(zhuǎn)換，將其從 Unicode轉(zhuǎn)換為 ANSI。
如果 DLL 函數(shù)不以任何方式處理文本，則可以忽略 DllImportAttribute 的 CharSet 屬性。然而，當(dāng) Char
或 String 數(shù)據(jù)是等式的一部分時，應(yīng)該將 CharSet 屬性設(shè)置為 CharSet.Auto。這樣可以使 CLR 根據(jù)宿主 OS
使用適當(dāng)?shù)淖址Ｈ绻麤]有顯式地設(shè)置 CharSet 屬性，則其默認值為 CharSet.Ansi。這個默認值是有缺點的，因為對于在
Windows 2000、Windows XP 和 Windows NT® 上進行的 interop
調(diào)用，它會消極地影響文本參數(shù)封送處理的性能。
應(yīng)該顯式地選擇 CharSet.Ansi 或 CharSet.Unicode 的 CharSet 值而不是使用 CharSet.Auto
的唯一情況是：您顯式地指定了一個導(dǎo)出函數(shù)，而該函數(shù)特定于這兩種 Win32 OS 中的某一種。ReadDirectoryChangesW
API 函數(shù)就是這樣的一個例子，它只存在于基于 Windows NT 的操作系統(tǒng)中，并且只支持 Unicode；在這種情況下，您應(yīng)該顯式地使用
CharSet.Unicode。
有時，Windows API 是否有字符集關(guān)系并不明顯。一種決不會有錯的確認方法是在 Platform SDK 中檢查該函數(shù)的 C
語言頭文件。（如果您無法肯定要看哪個頭文件，則可以查看 Platform SDK 文檔中列出的每個 API 函數(shù)的頭文件。）如果您發(fā)現(xiàn)該
API 函數(shù)確實定義為一個映射到以 A 或 W 結(jié)尾的函數(shù)名的宏，則字符集與您嘗試調(diào)用的函數(shù)有關(guān)系。Windows API 函數(shù)的一個例子是在
WinUser.h 中聲明的 GetMessage API，您也許會驚訝地發(fā)現(xiàn)它有 A 和 W 兩種版本。
SetLastError 錯誤處理非常重要，但在編程時經(jīng)常被遺忘。當(dāng)您進行 P/Invoke 調(diào)用時，也會面臨其他的挑戰(zhàn) — 處理托管代碼中 Windows API 錯誤處理和異常之間的區(qū)別。我可以給您一點建議。
如果您正在使用 P/Invoke 調(diào)用 Windows API 函數(shù)，而對于該函數(shù)，您使用 GetLastError
來查找擴展的錯誤信息，則應(yīng)該在外部方法的 DllImportAttribute 中將 SetLastError 屬性設(shè)置為
true。這適用于大多數(shù)外部方法。
這會導(dǎo)致 CLR 在每次調(diào)用外部方法之后緩存由 API 函數(shù)設(shè)置的錯誤。然后，在包裝方法中，可以通過調(diào)用類庫的
System.Runtime.InteropServices.Marshal 類型中定義的 Marshal.GetLastWin32Error
方法來獲取緩存的錯誤值。我的建議是檢查這些期望來自 API
函數(shù)的錯誤值，并為這些值引發(fā)一個可感知的異常。對于其他所有失敗情況（包括根本就沒意料到的失敗情況），則引發(fā)在
System.ComponentModel 命名空間中定義的 Win32Exception，并將
Marshal.GetLastWin32Error 返回的值傳遞給它。如果您回頭看一下圖 1 中的代碼，您會看到我在 extern
MessageBeep 方法的公共包裝中就采用了這種方法。
CallingConvention 我將在此介紹的最后也可能是最不重要的一個 DllImportAttribute 屬性是
CallingConvention。通過此屬性，可以給 CLR
指示應(yīng)該將哪種函數(shù)調(diào)用約定用于堆棧中的參數(shù)。CallingConvention.Winapi
的默認值是最好的選擇，它在大多數(shù)情況下都可行。然而，如果該調(diào)用不起作用，則可以檢查 Platform SDK 中的聲明頭文件，看看您調(diào)用的
API 函數(shù)是否是一個不符合調(diào)用約定標(biāo)準(zhǔn)的異常 API。
通常，本機函數(shù)（例如 Windows API 函數(shù)或 C- 運行時 DLL
函數(shù)）的調(diào)用約定描述了如何將參數(shù)推入線程堆棧或從線程堆棧中清除。大多數(shù) Windows API
函數(shù)都是首先將函數(shù)的最后一個參數(shù)推入堆棧，然后由被調(diào)用的函數(shù)負責(zé)清理該堆棧。相反，許多 C-運行時 DLL
函數(shù)都被定義為按照方法參數(shù)在方法簽名中出現(xiàn)的順序?qū)⑵渫迫攵褩＃瑢⒍褩Ｇ謇砉ぷ鹘唤o調(diào)用者。
幸運的是，要讓 P/Invoke 調(diào)用工作只需要讓外圍設(shè)備理解調(diào)用約定即可。通常，從默認值
CallingConvention.Winapi 開始是最好的選擇。然后，在 C 運行時 DLL 函數(shù)和少數(shù)函數(shù)中，可能需要將約定更改為
CallingConvention.Cdecl。
數(shù)據(jù)封送處理
數(shù)據(jù)封送處理是 P/Invoke 具有挑戰(zhàn)性的方面。當(dāng)在托管和非托管代碼之間傳遞數(shù)據(jù)時，CLR
遵循許多規(guī)則，很少有開發(fā)人員會經(jīng)常遇到它們直至可將這些規(guī)則記住。除非您是一名類庫開發(fā)人員，否則在通常情況下沒有必要掌握其細節(jié)。為了最有效地在
CLR 上使用 P/Invoke，即使只偶爾需要 interop 的應(yīng)用程序開發(fā)人員仍然應(yīng)該理解數(shù)據(jù)封送處理的一些基礎(chǔ)知識。
在本月專欄的剩余部分中，我將討論簡單數(shù)字和字符串?dāng)?shù)據(jù)的數(shù)據(jù)封送處理。我將從最基本的數(shù)字數(shù)據(jù)封送處理開始，然后介紹簡單的指針封送處理和字符串封送處理。
封送數(shù)字和邏輯標(biāo)量
Windows OS 大部分是用 C 編寫的。因此，Windows API 所用到的數(shù)據(jù)類型要么是 C 類型，要么是通過類型定義或宏定義重新標(biāo)記的 C 類型。讓我們看看沒有指針的數(shù)據(jù)封送處理。簡單起見，首先重點討論的是數(shù)字和布爾值。
當(dāng)通過值向 Windows API 函數(shù)傳遞參數(shù)時，需要知道以下問題的答案：
| • |
數(shù)據(jù)從根本上講是整型的還是浮點型的？
|
| • |
如果數(shù)據(jù)是整型的，則它是有符號的還是無符號的？
|
| • |
如果數(shù)據(jù)是整型的，則它的位數(shù)是多少？
|
| • |
如果數(shù)據(jù)是浮點型的，則它是單精度的還是雙精度的？
|
有時答案很明顯，但有時卻不明顯。Windows API 以各種方式重新定義了基本的 C 數(shù)據(jù)類型。圖 2 列出了 C 和 Win32 的一些公共數(shù)據(jù)類型及其規(guī)范，以及一個具有匹配規(guī)范的公共語言運行庫類型。
通常，只要您選擇一個其規(guī)范與該參數(shù)的 Win32 類型相匹配的 CLR 類型，您的代碼就能夠正常工作。不過也有一些特例。例如，在
Windows API 中定義的 BOOL 類型是一個有符號的 32 位整型。然而，BOOL 用于指示 Boolean 值 true 或
false。雖然您不用將 BOOL 參數(shù)作為 System.Int32 值封送，但是如果使用 System.Boolean
類型，就會獲得更合適的映射。字符類型的映射類似于 BOOL，因為有一個特定的 CLR 類型 (System.Char) 指出字符的含義。
在了解這些信息之后，逐步介紹示例可能是有幫助的。依然采用 beep 主題作為例子，讓我們來試一下 Kernel32.dll 低級
Beep，它會通過計算機的揚聲器發(fā)生嘟聲。這個方法的 Platform SDK 文檔可以在 Beep 中找到。本機 API
按以下方式進行記錄：
BOOL Beep(
DWORD dwFreq, // Frequency
DWORD dwDuration // Duration in milliseconds
);
在參數(shù)封送處理方面，您的工作是了解什么 CLR 數(shù)據(jù)類型與 Beep API 函數(shù)所使用的 DWORD 和 BOOL
數(shù)據(jù)類型相兼容。回顧一下圖 2 中的圖表，您將看到 DWORD 是一個 32 位的無符號整數(shù)值，如同 CLR 類型
System.UInt32。這意味著您可以使用 UInt32 值作為送往 Beep 的兩個參數(shù)。BOOL
返回值是一個非常有趣的情況，因為該圖表告訴我們，在 Win32 中，BOOL 是一個 32 位的有符號整數(shù)。因此，您可以使用
System.Int32 值作為來自 Beep 的返回值。然而，CLR 也定義了 System.Boolean 類型作為 Boolean
值的語義，所以應(yīng)該使用它來替代。CLR 默認將 System.Boolean 值封送為 32 位的有符號整數(shù)。此處所顯示的外部方法定義是用于
Beep 的結(jié)果 P/Invoke 方法：
[DllImport("Kernel32.dll", SetLastError=true)]
static extern Boolean Beep(
UInt32 frequency, UInt32 duration);
指針參數(shù)
許多 Windows API
函數(shù)將指針作為它們的一個或多個參數(shù)。指針增加了封送數(shù)據(jù)的復(fù)雜性，因為它們增加了一個間接層。如果沒有指針，您可以通過值在線程堆棧中傳遞數(shù)據(jù)。有了指
針，則可以通過引用傳遞數(shù)據(jù)，方法是將該數(shù)據(jù)的內(nèi)存地址推入線程堆棧中。然后，函數(shù)通過內(nèi)存地址間接訪問數(shù)據(jù)。使用托管代碼表示此附加間接層的方式有多
種。
在 C# 中，如果將方法參數(shù)定義為 ref 或 out，則數(shù)據(jù)通過引用而不是通過值傳遞。即使您沒有使用 Interop
也是這樣，但只是從一個托管方法調(diào)用到另一個托管方法。例如，如果通過 ref 傳遞 System.Int32
參數(shù)，則在線程堆棧中傳遞的是該數(shù)據(jù)的地址，而不是整數(shù)值本身。下面是一個定義為通過引用接收整數(shù)值的方法的示例：
void FlipInt32(ref Int32 num){
num = -num;
}
這里，F(xiàn)lipInt32 方法獲取一個 Int32 值的地址、訪問數(shù)據(jù)、對它求反，然后將求反過的值賦給原始變量。在以下代碼中，F(xiàn)lipInt32 方法會將調(diào)用程序的變量 x 的值從 10 更改為 -10：
Int32 x = 10;
FlipInt32(ref x);
在托管代碼中可以重用這種能力，將指針傳遞給非托管代碼。例如，F(xiàn)ileEncryptionStatus API 函數(shù)以 32 位無符號位掩碼的形式返回文件加密狀態(tài)。該 API 按以下所示方式進行記錄：
BOOL FileEncryptionStatus(
LPCTSTR lpFileName, // file name
LPDWORD lpStatus // encryption status
);
請注意，該函數(shù)并不使用它的返回值返回狀態(tài)，而是返回一個 Boolean
值，指示調(diào)用是否成功。在成功的情況下，實際的狀態(tài)值是通過第二個參數(shù)返回的。它的工作方式是調(diào)用程序向該函數(shù)傳遞指向一個 DWORD
變量的指針，而該 API 函數(shù)用狀態(tài)值填充指向的內(nèi)存位置。以下代碼片段顯示了一個調(diào)用非托管 FileEncryptionStatus
函數(shù)的可能外部方法定義：
[DllImport("Advapi32.dll", CharSet=CharSet.Auto)]
static extern Boolean FileEncryptionStatus(String filename,
out UInt32 status);
該定義使用 out 關(guān)鍵字來為 UInt32 狀態(tài)值指示 by-ref 參數(shù)。這里我也可以選擇 ref
關(guān)鍵字，實際上在運行時會產(chǎn)生相同的機器碼。out 關(guān)鍵字只是一個 by-ref 參數(shù)的規(guī)范，它向 C#
編譯器指示所傳遞的數(shù)據(jù)只在被調(diào)用的函數(shù)外部傳遞。相反，如果使用 ref 關(guān)鍵字，則編譯器會假定數(shù)據(jù)可以在被調(diào)用的函數(shù)的內(nèi)部和外部傳遞。
托管代碼中 out 和 ref 參數(shù)的另一個很好的方面是，地址作為 by-ref
參數(shù)傳遞的變量可以是線程堆棧中的一個本地變量、一個類或結(jié)構(gòu)的元素，也可以是具有合適數(shù)據(jù)類型的數(shù)組中的一個元素引用。調(diào)用程序的這種靈活性使得
by-ref 參數(shù)成為封送緩沖區(qū)指針以及單數(shù)值指針的一個很好的起點。只有在我發(fā)現(xiàn) ref 或 out
參數(shù)不符合我的需要的情況下，我才會考慮將指針封送為更復(fù)雜的 CLR 類型（例如類或數(shù)組對象）。
如果您不熟悉 C 語法或者調(diào)用 Windows API
函數(shù)，有時很難知道一個方法參數(shù)是否需要指針。一個常見的指示符是看參數(shù)類型是否是以字母 P 或 LP 開頭的，例如 LPDWORD 或
PINT。在這兩個例子中，LP 和 P 指示參數(shù)是一個指針，而它們指向的數(shù)據(jù)類型分別為 DWORD 或
INT。然而，在有些情況下，可以直接使用 C 語言語法中的星號 (*) 將 API 函數(shù)定義為指針。以下代碼片段展示了這方面的示例：
void TakesAPointer(DWORD* pNum);
可以看到，上述函數(shù)的唯一一個參數(shù)是指向 DWORD 變量的指針。
當(dāng)通過 P/Invoke 封送指針時，ref 和 out 只用于托管代碼中的值類型。當(dāng)一個參數(shù)的 CLR 類型使用 struct
關(guān)鍵字定義時，可以認為該參數(shù)是一個值類型。Out 和 ref
用于封送指向這些數(shù)據(jù)類型的指針，因為通常值類型變量是對象或數(shù)據(jù)，而在托管代碼中并沒有對值類型的引用。相反，當(dāng)封送引用類型對象時，并不需要
ref 和 out 關(guān)鍵字，因為變量已經(jīng)是對象的引用了。
如果您對引用類型和值類型之間的差別不是很熟悉，請查閱 2000 年 12 月 發(fā)行的 MSDN® Magazine，在 .NET
專欄的主題中可以找到更多信息。大多數(shù) CLR 類型都是引用類型；然而，除了 System.String 和
System.Object，所有的基元類型（例如 System.Int32 和 System.Boolean）都是值類型。
封送不透明 (Opaque) 指針：一種特殊情況
有時在 Windows API 中，方法傳遞或返回的指針是不透明的，這意味著該指針值從技術(shù)角度講是一個指針，但代碼卻不直接使用它。相反，代碼將該指針返回給 Windows 以便隨后進行重用。
一個非常常見的例子就是句柄的概念。在 Windows 中，內(nèi)部數(shù)據(jù)結(jié)構(gòu)（從文件到屏幕上的按鈕）在應(yīng)用程序代碼中都表示為句柄。句柄其實就是不透明的指針或有著指針寬度的數(shù)值，應(yīng)用程序用它來表示內(nèi)部的 OS 構(gòu)造。
少數(shù)情況下，API 函數(shù)也將不透明指針定義為 PVOID 或 LPVOID 類型。在 Windows API 的定義中，這些類型意思就是說該指針沒有類型。
當(dāng)一個不透明指針返回給您的應(yīng)用程序（或者您的應(yīng)用程序期望得到一個不透明指針）時，您應(yīng)該將參數(shù)或返回值封送為 CLR 中的一種特殊類型 —
System.IntPtr。當(dāng)您使用 IntPtr 類型時，通常不使用 out 或 ref 參數(shù)，因為 IntPtr
意為直接持有指針。不過，如果您將一個指針封送為一個指針，則對 IntPtr 使用 by-ref 參數(shù)是合適的。
在 CLR 類型系統(tǒng)中，System.IntPtr 類型有一個特殊的屬性。不像系統(tǒng)中的其他基類型，IntPtr
并沒有固定的大小。相反，它在運行時的大小是依底層操作系統(tǒng)的正常指針大小而定的。這意味著在 32 位的 Windows 中，IntPtr
變量的寬度是 32 位的，而在 64 位的 Windows 中，實時編譯器編譯的代碼會將 IntPtr 值看作 64
位的值。當(dāng)在托管代碼和非托管代碼之間封送不透明指針時，這種自動調(diào)節(jié)大小的特點十分有用。
請記住，任何返回或接受句柄的 API 函數(shù)其實操作的就是不透明指針。您的代碼應(yīng)該將 Windows 中的句柄封送成 System.IntPtr 值。
您可以在托管代碼中將 IntPtr 值強制轉(zhuǎn)換為 32 位或 64 位的整數(shù)值，或?qū)⒑笳邚娭妻D(zhuǎn)換為前者。然而，當(dāng)使用 Windows
API
函數(shù)時，因為指針應(yīng)是不透明的，所以除了存儲和傳遞給外部方法外，不能將它們另做它用。這種“只限存儲和傳遞”規(guī)則的兩個特例是當(dāng)您需要向外部方法傳遞
null 指針值和需要比較 IntPtr 值與 null 值的情況。為了做到這一點，您不能將零強制轉(zhuǎn)換為 System.IntPtr，而應(yīng)該在
IntPtr 類型上使用 Int32.Zero 靜態(tài)公共字段，以便獲得用于比較或賦值的 null 值。
封送文本
在編程時經(jīng)常要對文本數(shù)據(jù)進行處理。文本為 interop 制造了一些麻煩，這有兩個原因。首先，底層操作系統(tǒng)可能使用 Unicode
來表示字符串，也可能使用 ANSI。在極少數(shù)情況下，例如 MultiByteToWideChar API 函數(shù)的兩個參數(shù)在字符集上是不一致的。
第二個原因是，當(dāng)需要進行 P/Invoke 時，要處理文本還需要特別了解到 C 和 CLR 處理文本的方式是不同的。在 C
中，字符串實際上只是一個字符值數(shù)組，通常以 null 作為結(jié)束符。大多數(shù) Windows API 函數(shù)是按照以下條件處理字符串的：對于
ANSI，將其作為字符值數(shù)組；對于 Unicode，將其作為寬字符值數(shù)組。
幸運的是，CLR 被設(shè)計得相當(dāng)靈活，當(dāng)封送文本時問題得以輕松解決，而不用在意 Windows API 函數(shù)期望從您的應(yīng)用程序得到的是什么。這里是一些需要記住的主要考慮事項：
| • |
是您的應(yīng)用程序向 API 函數(shù)傳遞文本數(shù)據(jù)，還是 API 函數(shù)向您的應(yīng)用程序返回字符串?dāng)?shù)據(jù)？或者二者兼有？
|
| • |
您的外部方法應(yīng)該使用什么托管類型？
|
| • |
API 函數(shù)期望得到的是什么格式的非托管字符串？
|
我們首先解答最后一個問題。大多數(shù) Windows API 函數(shù)都帶有 LPTSTR 或 LPCTSTR
值。（從函數(shù)角度看）它們分別是可修改和不可修改的緩沖區(qū)，包含以 null
結(jié)束的字符數(shù)組。“C”代表常數(shù)，意味著使用該參數(shù)信息不會傳遞到函數(shù)外部。LPTSTR 中的“T”表明該參數(shù)可以是 Unicode 或
ANSI，取決于您選擇的字符集和底層操作系統(tǒng)的字符集。因為在 Windows API 中大多數(shù)字符串參數(shù)都是這兩種類型之一，所以只要在
DllImportAttribute 中選擇 CharSet.Auto，CLR 就按默認的方式工作。
然而，有些 API 函數(shù)或自定義的 DLL 函數(shù)采用不同的方式表示字符串。如果您要用到一個這樣的函數(shù)，就可以采用
MarshalAsAttribute 修飾外部方法的字符串參數(shù)，并指明一種不同于默認 LPTSTR 的字符串格式。有關(guān)
MarshalAsAttribute 的更多信息，請參閱位于 MarshalAsAttribute Class 的 Platform SDK
文檔主題。
現(xiàn)在讓我們看一下字符串信息在您的代碼和非托管函數(shù)之間傳遞的方向。有兩種方式可以知道處理字符串時信息的傳遞方向。第一個也是最可靠的一個方法就
是首先理解參數(shù)的用途。例如，您正調(diào)用一個參數(shù)，它的名稱類似 CreateMutex 并帶有一個字符串，則可以想像該字符串信息是從應(yīng)用程序向
API 函數(shù)傳遞的。同時，如果您調(diào)用 GetUserName，則該函數(shù)的名稱表明字符串信息是從該函數(shù)向您的應(yīng)用程序傳遞的。
除了這種比較合理的方法外，第二種查找信息傳遞方向的方式就是查找 API 參數(shù)類型中的字母“C”。例如，GetUserName API
函數(shù)的第一個參數(shù)被定義為 LPTSTR 類型，它代表一個指向 Unicode 或 ANSI 字符串緩沖區(qū)的長指針。但是 CreateMutex
的名稱參數(shù)被類型化為 LTCTSTR。請注意，這里的類型定義是一樣的，但增加一個字母“C”來表明緩沖區(qū)為常數(shù)，API 函數(shù)不能寫入。
一旦明確了文本參數(shù)是只用作輸入還是用作輸入/輸出，就可以確定使用哪種 CLR 類型作為參數(shù)類型。這里有一些規(guī)則。如果字符串參數(shù)只用作輸入，則使用 System.String 類型。在托管代碼中，字符串是不變的，適合用于不會被本機 API 函數(shù)更改的緩沖區(qū)。
如果字符串參數(shù)可以用作輸入和/或輸出，則使用 System.StringBuilder 類型。StringBuilder
類型是一個很有用的類庫類型，它可以幫助您有效地構(gòu)建字符串，也正好可以將緩沖區(qū)傳遞給本機函數(shù)，由本機函數(shù)為您填充字符串?dāng)?shù)據(jù)。一旦函數(shù)調(diào)用返回，您只
需要調(diào)用 StringBuilder 對象的 ToString 就可以得到一個 String 對象。
GetShortPathName API 函數(shù)能很好地用于顯示什么時候使用 String、什么時候使用 StringBuilder，因為它只帶有三個參數(shù)：一個輸入字符串、一個輸出字符串和一個指明輸出緩沖區(qū)的字符長度的參數(shù)。
圖 3 所示為加注釋的非托管 GetShortPathName
函數(shù)文檔，它同時指出了輸入和輸出字符串參數(shù)。它引出了托管的外部方法定義，也如圖 3 所示。請注意第一個參數(shù)被封送為
System.String，因為它是一個只用作輸入的參數(shù)。第二個參數(shù)代表一個輸出緩沖區(qū)，它使用了 System.StringBuilder。
小結(jié)
本月專欄所介紹的 P/Invoke 功能足夠調(diào)用 Windows 中的許多 API 函數(shù)。然而，如果您大量用到
interop，則會最終發(fā)現(xiàn)自己封送了很復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，甚至可能需要在托管代碼中通過指針直接訪問內(nèi)存。實際上，本機代碼中的 interop
可以是一個將細節(jié)和低級比特藏在里面的真正的潘多拉盒子。CLR、C# 和托管 C++ 提供了許多有用的功能；也許以后我會在本專欄介紹高級的
P/Invoke 話題。
同時，只要您覺得 .NET Framework 類庫無法播放您的聲音或者為您執(zhí)行其他一些功能，您可以知道如何向原始而優(yōu)秀的 Windows API 尋求一些幫助。
Figure 1 MessageBeep, Interop Done Well
namespace Wintellect.Interop.Sound{
using System;
using System.Runtime.InteropServices;
using System.ComponentModel;
sealed class Sound{
public static void MessageBeep(BeepTypes type){
if(!MessageBeep((UInt32) type)){
Int32 err = Marshal.GetLastWin32Error();
throw new Win32Exception(err);
}
}
[DllImport("User32.dll", SetLastError=true)]
static extern Boolean MessageBeep(UInt32 beepType);
private Sound(){}
}
enum BeepTypes{
Simple = -1,
Ok = 0x00000000,
IconHand = 0x00000010,
IconQuestion = 0x00000020,
IconExclamation = 0x00000030,
IconAsterisk = 0x00000040
}
}
Figure 2 Non-Pointer Data Types
| Win32 Types | Specification | CLR Type |
| char, INT8, SBYTE, CHAR†|
8-bit signed integer |
System.SByte |
| short, short int, INT16, SHORT |
16-bit signed integer |
System.Int16 |
| int, long, long int, INT32, LONG32, BOOL†, INT |
32-bit signed integer |
System.Int32 |
| __int64, INT64, LONGLONG |
64-bit signed integer |
System.Int64 |
| unsigned char, UINT8, UCHAR†, BYTE |
8-bit unsigned integer |
System.Byte |
| unsigned short, UINT16, USHORT, WORD, ATOM, WCHAR†, __wchar_t |
16-bit unsigned integer |
System.UInt16 |
| unsigned, unsigned int, UINT32, ULONG32, DWORD32, ULONG, DWORD, UINT |
32-bit unsigned integer |
System.UInt32 |
| unsigned __int64, UINT64, DWORDLONG, ULONGLONG |
64-bit unsigned integer |
System.UInt64 |
| float, FLOAT |
Single-precision floating point |
System.Single |
| double, long double, DOUBLE |
Double-precision floating point |
System.Double |
| †In Win32 this type is an integer with a specially assigned meaning; in contrast, the CLR provides a specific type devoted to this meaning. |
Figure 3 GetShortPathName Declarations
// ** Documentation for Win32 GetShortPathName() API Function
// DWORD GetShortPathName(
// LPCTSTR lpszLongPath, // file for which to get short path
// LPTSTR lpszShortPath, // short path name (output)
// DWORD cchBuffer // size of output buffer
// );
[DllImport("Kernel32", CharSet = CharSet.Auto)]
static extern Int32 GetShortPathName(
String path, // input string
StringBuilder shortPath, // output string
Int32 shortPathLength); // StringBuilder.Capacity