C# API應用整理文檔

C:\ProgramFiles\MicrosoftVisual Studio .Net\ FrameworkSDK\Samples\ TechnologIEs\ Interop\PlatformInvoke\ WinAPIs\CS目錄下有大量的調用API的例子。 一、調用格式 using System.Runtime.InteropServices; //引用此名稱空間，簡化後面的代碼 //使用DllImportAttribute特性來引入api函數，注意聲明的是空方法，即方法體為空。 [DllImport("user32.dll")] public static extern ReturnType FunctionName(type arg1,type arg2,...); //調用時與調用其他方法並無區別 可以使用字段進一步說明特性，用逗號隔開，如： [ DllImport( "kernel32", EntryPoint="GetVersionEx" )] DllImportAttribute特性的公共字段如下： 1、CallingConvention 指示向非托管實現傳遞方法參數時所用的 CallingConvention 值。 CallingConvention.Cdecl : 調用方清理堆棧。它使您能夠調用具有 varargs 的函數。 CallingConvention.StdCall : 被調用方清理堆棧。它是從托管代碼調用非托管函數的默認約定。 2、CharSet 控制調用函數的名稱版本及指示如何向方法封送 String 參數。 此字段被設置為 CharSet 值之一。如果 CharSet 字段設置為 Unicode，則所有字符串參數在傳遞到非托管實現之前都轉換成 Unicode 字符。這還導致向 DLL EntryPoint 的名稱中追加字母“W”。如果此字段設置為 Ansi，則字符串將轉換成 ANSI 字符串，同時向 DLL EntryPoint 的名稱中追加字母“A”。大多數 Win32 API 使用這種追加“W”或“A”的約定。如果 CharSet 設置為 Auto，則這種轉換就是與平台有關的（在 Windows NT 上為 Unicode，在 Windows 98 上為 Ansi）。CharSet 的默認值為 Ansi。CharSet 字段也用於確定將從指定的 DLL 導入哪個版本的函數。CharSet.Ansi 和 CharSet.Unicode 的名稱匹配規則大不相同。對於 Ansi 來說，如果將 EntryPoint 設置為“MyMethod”且它存在的話，則返回“MyMethod”。如果 DLL 中沒有“MyMethod”，但存在“MyMethodA”，則返回“MyMethodA”。對於 Unicode 來說則正好相反。如果將 EntryPoint 設置為“MyMethod”且它存在的話，則返回“MyMethodW”。如果 DLL 中不存在“MyMethodW”，但存在“MyMethod”，則返回“MyMethod”。如果使用的是 Auto，則匹配規則與平台有關（在 Windows NT 上為 Unicode，在 Windows 98 上為 Ansi）。如果 ExactSpelling 設置為 true，則只有當 DLL 中存在“MyMethod”時才返回“MyMethod”。     3、EntryPoint 指示要調用的 DLL 入口點的名稱或序號。 如果你的方法名不想與api函數同名的話，一定要指定此參數,例如： [DllImport("user32.dll",CharSet="CharSet.Auto",EntryPoint="MessageBox")] public static extern int MsgBox(IntPtr hWnd,string txt,string caption, int type);     4、ExactSpelling 指示是否應修改非托管 DLL 中的入口點的名稱，以與 CharSet 字段中指定的 CharSet 值相對應。如果為 true，則當 DllImportAttribute.CharSet 字段設置為 CharSet 的 Ansi 值時，向方法名稱中追加字母 A，當 DllImportAttribute.CharSet 字段設置為 CharSet 的 Unicode 值時，向方法的名稱中追加字母 W。此字段的默認值是 false。 5、PreserveSig 指示托管方法簽名不應轉換成返回 HRESULT、並且可能有一個對應於返回值的附加 [out, retval] 參數的非托管簽名。 6、SetLastError 指示被調用方在從屬性化方法返回之前將調用 Win32 API SetLastError。 true 指示調用方將調用 SetLastError，默認為 false。運行時封送拆收器將調用 GetLastError 並緩存返回的值，以防其被其他 API 調用重寫。用戶可通過調用 GetLastWin32Error 來檢索錯誤代碼。   二、參數類型： 1、數值型直接用對應的就可。（DWORD -> int , Word -> Int16） 2、API中字符串指針類型 -> .Net中string 3、API中句柄 (dWord) -> .Net中IntPtr 4、API中結構 -> .Net中結構或者類。注意這種情況下，要先用StructLayout特性限定聲明結構或類 公共語言運行庫利用StructLayoutAttribute控制類或結構的數據字段在托管內存中的物理布局,即類或結構需要按某種方式排列。如果要將類傳遞給需要指定布局的非托管代碼，則顯式控制類布局是重要的。它的構造函數中用LayoutKind值初始化 StructLayoutAttribute 類的新實例。 LayoutKind.Sequential 用於強制將成員按其出現的順序進行順序布局。 LayoutKind.Explicit 用於控制每個數據成員的精確位置。利用 Explicit， 每個成員必須使用 FIEldOffsetAttribute 指示此字段在類型中的位置。如： [StructLayout(LayoutKind.Explicit, Size=16, CharSet=CharSet.Ansi)] public class MySystemTime { [FIEldOffset(0)]public ushort wYear; [FIEldOffset(2)]public ushort wMonth; [FIEldOffset(4)]public ushort wDayOfWeek; [FIEldOffset(6)]public ushort wDay; [FIEldOffset(8)]public ushort wHour; [FIEldOffset(10)]public ushort wMinute; [FIEldOffset(12)]public ushort wSecond; [FIEldOffset(14)]public ushort wMilliseconds; } 下面是針對API中OSVERSIONINFO結構，在.Net中定義對應類或結構的例子： /********************************************** * API中定義原結構聲明 * OSVERSIONINFOA STRUCT * dwOSVersionInfoSize DWord ? * dwMajorVersion DWord ? * dwMinorVersion DWord ? * dwBuildNumber DWord ? * dwPlatformId DWord ? * szCSDVersion BYTE 128 dup (?) * OSVERSIONINFOA ENDS * * OSVERSIONINFO equ <OSVERSIONINFOA> *********************************************/     //.Net中聲明為類 [ StructLayout( LayoutKind.Sequential )] public class OSVersionInfo { public int OSVersionInfoSize; public int majorVersion; public int minorVersion; public int buildNumber; public int platformId;     [ MarshalAs( UnmanagedType.ByValTStr, SizeConst=128 )] public String versionString; } //或者 //.Net中聲明為結構 [ StructLayout( LayoutKind.Sequential )] public struct OSVersionInfo2 { public int OSVersionInfoSize; public int majorVersion; public int minorVersion; public int buildNumber; public int platformId;     [ MarshalAs( UnmanagedType.ByValTStr, SizeConst=128 )] public String versionString; }   此例中用到MashalAs特性，它用於描述字段、方法或參數的封送處理格式。用它作為參數前綴並指定目標需要的數據類型。例如，以下代碼將兩個參數作為數據類型長指針封送給 Windows API 函數的字符串 (LPStr)： [MarshalAs(UnmanagedType.LPStr)] String existingfile; [MarshalAs(UnmanagedType.LPStr)] String newfile;   注意結構作為參數時候，一般前面要加上ref修飾符，否則會出現錯誤：對象的引用沒有指定對象的實例。 [ DllImport( "kernel32", EntryPoint="GetVersionEx" )] public static extern bool GetVersionEx2( ref OSVersionInfo2 osvi );   三、如何保證使用托管對象的平台調用成功？ 如果在調用平台 invoke 後的任何位置都未引用托管對象，則垃圾回收器可能將完成該托管對象。這將釋放資源並使句柄無效，從而導致平台invoke 調用失敗。用 HandleRef 包裝句柄可保證在平台 invoke 調用完成前，不對托管對象進行垃圾回收。 例如下面： FileStream fs = new FileStream( "a.txt", FileMode.Open ); StringBuilder buffer = new StringBuilder( 5 ); int read = 0; ReadFile(fs.Handle, buffer, 5, out read, 0 ); //調用Win API中的ReadFile函數 由於fs是托管對象，所以有可能在平台調用還未完成時候被垃圾回收站回收。將文件流的句柄用HandleRef包裝後，就能避免被垃圾站回收: [ DllImport( "Kernel32.dll" )] public static extern bool ReadFile( HandleRef hndRef, StringBuilder buffer, int numberOfBytesToRead, out int numberOfBytesRead, ref Overlapped flag ); ...... ...... FileStream fs = new FileStream( "HandleRef.txt", FileMode.Open ); HandleRef hr = new HandleRef( fs, fs.Handle ); StringBuilder buffer = new StringBuilder( 5 ); int read = 0; // platform invoke will hold reference to HandleRef until call ends ReadFile( hr, buffer, 5, out read, 0 );         我在自己最近的編程中注意到一個趨勢，正是這個趨勢才引出本月的專欄主題。最近，我在基於 Microsoft? .Net Framework 的應用程序中完成了大量的 Win32? Interop。我並不是要說我的應用程序充滿了自定義的 interop 代碼，但有時我會在 .Net Framework 類庫中碰到一些次要但又繁絮、不充分的內容，通過調用該 Windows? API，可以快速減少這樣的麻煩。   因此我認為，.Net Framework 1.0 或 1.1 版類庫中存在任何 Windows 所沒有的功能限制都不足為怪。畢竟，32 位的 Windows（不管何種版本）是一個成熟的操作系統，為廣大客戶服務了十多年。相比之下，.Net Framework 卻是一個新事物。   隨著越來越多的開發人員將生產應用程序轉到托管代碼，開發人員更頻繁地研究底層操作系統以圖找出一些關鍵功能顯得很自然 — 至少目前是如此。   值得慶幸的是，公共語言運行庫 (CLR) 的 interop 功能（稱為平台調用 (P/Invoke)）非常完善。在本專欄中，我將重點介紹如何實際使用 P/Invoke 來調用 Windows API 函數。當指 CLR 的 COM Interop 功能時，P/Invoke 當作名詞使用；當指該功能的使用時，則將其當作動詞使用。我並不打算直接介紹 COM Interop，因為它比 P/Invoke 具有更好的可訪問性，卻更加復雜，這有點自相矛盾，這使得將 COM Interop 作為專欄主題來討論不太簡明扼要。   走進 P/Invoke   首先從考察一個簡單的 P/Invoke 示例開始。讓我們看一看如何調用 Win32 MessageBeep 函數，它的非托管聲明如以下代碼所示：   BOOL MessageBeep(   UINT uType   // beep type );   為了調用 MessageBeep，您需要在 C# 中將以下代碼添加到一個類或結構定義中：   [DllImport("User32.dll")] static extern Boolean MessageBeep(UInt32 beepType);   令人驚訝的是，只需要這段代碼就可以使托管代碼調用非托管的 MessageBeep API。它不是一個方法調用，而是一個外部方法定義。（另外，它接近於一個來自 C 而 C# 允許的直接端口，因此以它為起點來介紹一些概念是有幫助的。）來自托管代碼的可能調用如下所示：   MessageBeep(0);   請注意，現在 MessageBeep 方法被聲明為 static。這是 P/Invoke 方法所要求的，因為在該 Windows API 中沒有一致的實例概念。接下來，還要注意該方法被標記為 extern。這是提示編譯器該方法是通過一個從 DLL 導出的函數實現的，因此不需要提供方法體。   說到缺少方法體，您是否注意到 MessageBeep 聲明並沒有包含一個方法體？與大多數算法由中間語言 (IL) 指令組成的托管方法不同，P/Invoke 方法只是元數據，實時 (JIT) 編譯器在運行時通過它將托管代碼與非托管的 DLL 函數連接起來。執行這種到非托管世界的連接所需的一個重要信息就是導出非托管方法的 DLL 的名稱。這一信息是由 MessageBeep 方法聲明之前的 DllImport 自定義屬性提供的。在本例中，可以看到，MessageBeep 非托管 API 是由 Windows 中的 User32.dll 導出的。   到現在為止，關於調用 MessageBeep 就剩兩個話題沒有介紹，請回顧一下，調用的代碼與以下所示代碼片段非常相似：   [DllImport("User32.dll")] static extern Boolean MessageBeep(UInt32 beepType);   最後這兩個話題是與數據封送處理 (data marshaling) 和從托管代碼到非托管函數的實際方法調用有關的話題。調用非托管 MessageBeep 函數可以由找到作用域內的extern MessageBeep 聲明的任何托管代碼執行。該調用類似於任何其他對靜態方法的調用。它與其他任何托管方法調用的共同之處在於帶來了數據封送處理的需要。   C# 的規則之一是它的調用語法只能訪問 CLR 數據類型，例如 System.UInt32 和 System.Boolean。C# 顯然不識別 Windows API 中使用的基於 C 的數據類型（例如 UINT 和 BOOL），這些類型只是 C 語言類型的類型定義而已。所以當 Windows API 函數 MessageBeep 按以下方式編寫時   BOOL MessageBeep( UINT uType )   外部方法就必須使用 CLR 類型來定義，如您在前面的代碼片段中所看到的。需要使用與基礎 API 函數類型不同但與之兼容的 CLR 類型是 P/Invoke 較難使用的一個方面。因此，在本專欄的後面我將用完整的章節來介紹數據封送處理。   樣式   在 C# 中對 Windows API 進行 P/Invoke 調用是很簡單的。但如果類庫拒絕使您的應用程序發出嘟聲，應該想方設法調用 Windows 使它進行這項工作，是嗎？   是的。但是與選擇的方法有關，而且關系甚大！通常，如果類庫提供某種途徑來實現您的意圖，則最好使用 API 而不要直接調用非托管代碼，因為 CLR 類型和 Win32 之間在樣式上有很大的不同。我可以將關於這個問題的建議歸結為一句話。當您進行 P/Invoke 時，不要使應用程序邏輯直接屬於任何外部方法或其中的構件。如果您遵循這個小規則，從長遠看經常會省去許多的麻煩。   圖 1 中的代碼顯示了我所討論的 MessageBeep 外部方法的最少附加代碼。圖 1 中並沒有任何顯著的變化，而只是對無包裝的外部方法進行一些普通的改進，這可以使工作更加輕松一些。從頂部開始，您會注意到一個名為 Sound 的完整類型，它專用於 MessageBeep。如果我需要使用 Windows API 函數 PlaySound 來添加對播放波形的支持，則可以重用 Sound 類型。然而，我不會因公開單個公共靜態方法的類型而生氣。畢竟這只是應用程序代碼而已。還應該注意到，Sound 是密封的，並定義了一個空的私有構造函數。這些只是一些細節，目的是使用戶不會錯誤地從 Sound 派生類或者創建它的實例。   圖 1 中的代碼的下一個特征是，P/Invoke 出現位置的實際外部方法是 Sound 的私有方法。這個方法只是由公共 MessageBeep 方法間接公開，後者接受 BeepTypes 類型的參數。這個間接的額外層是一個很關鍵的細節，它提供了以下好處。首先，應該在類庫中引入一個未來的 beep 托管方法，可以重復地通過公共 MessageBeep 方法來使用托管 API，而不必更改應用程序中的其余代碼。   該包裝方法的第二個好處是：當您進行 P/Invoke 調用時，您放棄了免受訪問沖突和其他低級破壞的權利，這通常是由 CLR 提供的。緩沖方法可以保護您的應用程序的其余部分免受訪問沖突及類似問題的影響（即使它不做任何事而只是傳遞參數）。該緩沖方法將由 P/Invoke 調用引入的任何潛在的錯誤本地化。   將私有外部方法隱藏在公共包裝後面的第三同時也是最後的一個好處是，提供了向該方法添加一些最小的 CLR 樣式的機會。例如，在圖 1 中，我將 Windows API 函數返回的 Boolean 失敗轉換成更像 CLR 的異常。我還定義了一個名為 BeepTypes 的枚舉類型，它的成員對應於同該 Windows API 一起使用的定義值。由於 C# 不支持定義，因此可以使用托管枚舉類型來避免幻數向整個應用程序代碼擴散。   包裝方法的最後一個好處對於簡單的 Windows API 函數（如 MessageBeep）誠然是微不足道的。但是當您開始調用更復雜的非托管函數時，您會發現，手動將 Windows API 樣式轉換成對 CLR 更加友好的方法所帶來的好處會越來越多。越是打算在整個應用程序中重用 interop 功能，越是應該認真地考慮包裝的設計。同時我認為，在非面向對象的靜態包裝方法中使用對 CLR 友好的參數也並非不可以。   DLL Import 屬性   現在是更深入地進行探討的時候了。在對托管代碼進行 P/Invoke 調用時，DllImportAttribute 類型扮演著重要的角色。DllImportAttribute 的主要作用是給 CLR 指示哪個 DLL 導出您想要調用的函數。相關 DLL 的名稱被作為一個構造函數參數傳遞給 DllImportAttribute。   如果您無法肯定哪個 DLL 定義了您要使用的 Windows API 函數，Platform SDK 文檔將為您提供最好的幫助資源。在 Windows API 函數主題文字臨近結尾的位置，SDK 文檔指定了 C 應用程序要使用該函數必須鏈接的 .lib 文件。在幾乎所有的情況下，該 .lib 文件具有與定義該函數的系統 DLL 文件相同的名稱。例如，如果該函數需要 C 應用程序鏈接到 Kernel32.lib，則該函數就定義在 Kernel32.dll 中。您可以在 MessageBeep 中找到有關 MessageBeep 的 Platform SDK 文檔主題。在該主題結尾處，您會注意到它指出庫文件是 User32.lib；這表明 MessageBeep 是從 User32.dll 中導出的。   可選的 DllImportAttribute 屬性   除了指出宿主 DLL 外，DllImportAttribute 還包含了一些可選屬性，其中四個特別有趣：EntryPoint、CharSet、SetLastError 和 CallingConvention。   EntryPoint 在不希望外部托管方法具有與 DLL 導出相同的名稱的情況下，可以設置該屬性來指示導出的 DLL 函數的入口點名稱。當您定義兩個調用相同非托管函數的外部方法時，這特別有用。另外，在 Windows 中還可以通過它們的序號值綁定到導出的 DLL 函數。如果您需要這樣做，則諸如“#1”或“#129”的 EntryPoint 值指示 DLL 中非托管函數的序號值而不是函數名。   CharSet 對於字符集，並非所有版本的 Windows 都是同樣創建的。Windows 9x 系列產品缺少重要的 Unicode 支持，而 Windows NT 和 Windows CE 系列則一開始就使用 Unicode。在這些操作系統上運行的 CLR 將Unicode 用於 String 和 Char 數據的內部表示。但也不必擔心 — 當調用 Windows 9x API 函數時，CLR 會自動進行必要的轉換，將其從 Unicode轉換為 ANSI。   如果 DLL 函數不以任何方式處理文本，則可以忽略 DllImportAttribute 的 CharSet 屬性。然而，當 Char 或 String 數據是等式的一部分時，應該將 CharSet 屬性設置為 CharSet.Auto。這樣可以使 CLR 根據宿主 OS 使用適當的字符集。如果沒有顯式地設置 CharSet 屬性，則其默認值為 CharSet.Ansi。這個默認值是有缺點的，因為對於在 Windows 2000、Windows XP 和 Windows NT? 上進行的 interop 調用，它會消極地影響文本參數封送處理的性能。   應該顯式地選擇 CharSet.Ansi 或 CharSet.Unicode 的 CharSet 值而不是使用 CharSet.Auto 的唯一情況是：您顯式地指定了一個導出函數，而該函數特定於這兩種 Win32 OS 中的某一種。ReadDirectoryChangesW API 函數就是這樣的一個例子，它只存在於基於 Windows NT 的操作系統中，並且只支持 Unicode；在這種情況下，您應該顯式地使用 CharSet.Unicode。   有時，Windows API 是否有字符集關系並不明顯。一種決不會有錯的確認方法是在 Platform SDK 中檢查該函數的 C 語言頭文件。（如果您無法肯定要看哪個頭文件，則可以查看 Platform SDK 文檔中列出的每個 API 函數的頭文件。）如果您發現該 API 函數確實定義為一個映射到以 A 或 W 結尾的函數名的宏，則字符集與您嘗試調用的函數有關系。Windows API 函數的一個例子是在 WinUser.h 中聲明的 GetMessage API，您也許會驚訝地發現它有 A 和 W 兩種版本。   SetLastError 錯誤處理非常重要，但在編程時經常被遺忘。當您進行 P/Invoke 調用時，也會面臨其他的挑戰 — 處理托管代碼中 Windows API 錯誤處理和異常之間的區別。我可以給您一點建議。   如果您正在使用 P/Invoke 調用 Windows API 函數，而對於該函數，您使用 GetLastError 來查找擴展的錯誤信息，則應該在外部方法的 DllImportAttribute 中將 SetLastError 屬性設置為 true。這適用於大多數外部方法。   這會導致 CLR 在每次調用外部方法之後緩存由 API 函數設置的錯誤。然後，在包裝方法中，可以通過調用類庫的 System.Runtime.InteropServices.Marshal 類型中定義的 Marshal.GetLastWin32Error 方法來獲取緩存的錯誤值。我的建議是檢查這些期望來自 API 函數的錯誤值，並為這些值引發一個可感知的異常。對於其他所有失敗情況（包括根本就沒意料到的失敗情況），則引發在 System.ComponentModel 命名空間中定義的 Win32Exception，並將 Marshal.GetLastWin32Error 返回的值傳遞給它。如果您回頭看一下圖 1 中的代碼，您會看到我在 extern MessageBeep 方法的公共包裝中就采用了這種方法。   CallingConvention 我將在此介紹的最後也可能是最不重要的一個 DllImportAttribute 屬性是 CallingConvention。通過此屬性，可以給 CLR 指示應該將哪種函數調用約定用於堆棧中的參數。CallingConvention.Winapi 的默認值是最好的選擇，它在大多數情況下都可行。然而，如果該調用不起作用，則可以檢查 Platform SDK 中的聲明頭文件，看看您調用的 API 函數是否是一個不符合調用約定標准的異常 API。   通常，本機函數（例如 Windows API 函數或 C- 運行時 DLL 函數）的調用約定描述了如何將參數推入線程堆棧或從線程堆棧中清除。大多數 Windows API 函數都是首先將函數的最後一個參數推入堆棧，然後由被調用的函數負責清理該堆棧。相反，許多 C-運行時 DLL 函數都被定義為按照方法參數在方法簽名中出現的順序將其推入堆棧，將堆棧清理工作交給調用者。   幸運的是，要讓 P/Invoke 調用工作只需要讓外圍設備理解調用約定即可。通常，從默認值 CallingConvention.Winapi 開始是最好的選擇。然後，在 C 運行時 DLL 函數和少數函數中，可能需要將約定更改為 CallingConvention.Cdecl。   數據封送處理   數據封送處理是 P/Invoke 具有挑戰性的方面。當在托管和非托管代碼之間傳遞數據時，CLR 遵循許多規則，很少有開發人員會經常遇到它們直至可將這些規則記住。除非您是一名類庫開發人員，否則在通常情況下沒有必要掌握其細節。為了最有效地在 CLR 上使用 P/Invoke，即使只偶爾需要 interop 的應用程序開發人員仍然應該理解數據封送處理的一些基礎知識。   在本月專欄的剩余部分中，我將討論簡單數字和字符串數據的數據封送處理。我將從最基本的數字數據封送處理開始，然後介紹簡單的指針封送處理和字符串封送處理。   封送數字和邏輯標量   Windows OS 大部分是用 C 編寫的。因此，Windows API 所用到的數據類型要麼是 C 類型，要麼是通過類型定義或宏定義重新標記的 C 類型。讓我們看看沒有指針的數據封送處理。簡單起見，首先重點討論的是數字和布爾值。   當通過值向 Windows API 函數傳遞參數時，需要知道以下問題的答案：   ? 數據從根本上講是整型的還是浮點型的？   ? 如果數據是整型的，則它是有符號的還是無符號的？   ? 如果數據是整型的，則它的位數是多少？   ? 如果數據是浮點型的，則它是單精度的還是雙精度的？     有時答案很明顯，但有時卻不明顯。Windows API 以各種方式重新定義了基本的 C 數據類型。圖 2 列出了 C 和 Win32 的一些公共數據類型及其規范，以及一個具有匹配規范的公共語言運行庫類型。   通常，只要您選擇一個其規范與該參數的 Win32 類型相匹配的 CLR 類型，您的代碼就能夠正常工作。不過也有一些特例。例如，在 Windows API 中定義的 BOOL 類型是一個有符號的 32 位整型。然而，BOOL 用於指示 Boolean 值 true 或 false。雖然您不用將 BOOL 參數作為 System.Int32 值封送，但是如果使用 System.Boolean 類型，就會獲得更合適的映射。字符類型的映射類似於 BOOL，因為有一個特定的 CLR 類型 (System.Char) 指出字符的含義。   在了解這些信息之後，逐步介紹示例可能是有幫助的。依然采用 beep 主題作為例子，讓我們來試一下 Kernel32.dll 低級 Beep，它會通過計算機的揚聲器發生嘟聲。這個方法的 Platform SDK 文檔可以在 Beep 中找到。本機 API 按以下方式進行記錄：   BOOL Beep(   DWord dwFreq,      // Frequency   DWord dwDuration   // Duration in milliseconds );   在參數封送處理方面，您的工作是了解什麼 CLR 數據類型與 Beep API 函數所使用的 DWord 和 BOOL 數據類型相兼容。回顧一下圖 2 中的圖表，您將看到 DWord 是一個 32 位的無符號整數值，如同 CLR 類型 System.UInt32。這意味著您可以使用 UInt32 值作為送往 Beep 的兩個參數。BOOL 返回值是一個非常有趣的情況，因為該圖表告訴我們，在 Win32 中，BOOL 是一個 32 位的有符號整數。因此，您可以使用 System.Int32 值作為來自 Beep 的返回值。然而，CLR 也定義了 System.Boolean 類型作為 Boolean 值的語義，所以應該使用它來替代。CLR 默認將 System.Boolean 值封送為 32 位的有符號整數。此處所顯示的外部方法定義是用於 Beep 的結果 P/Invoke 方法：   [DllImport("Kernel32.dll", SetLastError=true)] static extern Boolean Beep(    UInt32 frequency, UInt32 duration);   指針參數   許多 Windows API 函數將指針作為它們的一個或多個參數。指針增加了封送數據的復雜性，因為它們增加了一個間接層。如果沒有指針，您可以通過值在線程堆棧中傳遞數據。有了指針，則可以通過引用傳遞數據，方法是將該數據的內存地址推入線程堆棧中。然後，函數通過內存地址間接訪問數據。使用托管代碼表示此附加間接層的方式有多種。   在 C# 中，如果將方法參數定義為 ref 或 out，則數據通過引用而不是通過值傳遞。即使您沒有使用 Interop 也是這樣，但只是從一個托管方法調用到另一個托管方法。例如，如果通過 ref 傳遞 System.Int32 參數，則在線程堆棧中傳遞的是該數據的地址，而不是整數值本身。下面是一個定義為通過引用接收整數值的方法的示例：   void FlipInt32(ref Int32 num){    num = -num; }   這裡，FlipInt32 方法獲取一個 Int32 值的地址、訪問數據、對它求反，然後將求反過的值賦給原始變量。在以下代碼中，FlipInt32 方法會將調用程序的變量 x 的值從 10 更改為 -10：   Int32 x = 10; FlipInt32(ref x);   在托管代碼中可以重用這種能力，將指針傳遞給非托管代碼。例如，FileEncryptionStatus API 函數以 32 位無符號位掩碼的形式返回文件加密狀態。該 API 按以下所示方式進行記錄：   BOOL FileEncryptionStatus(   LPCTSTR lpFileName,  // file name   LPDWord lpStatus     // encryption status );   請注意，該函數並不使用它的返回值返回狀態，而是返回一個 Boolean 值，指示調用是否成功。在成功的情況下，實際的狀態值是通過第二個參數返回的。它的工作方式是調用程序向該函數傳遞指向一個 DWord 變量的指針，而該 API 函數用狀態值填充指向的內存位置。以下代碼片段顯示了一個調用非托管 FileEncryptionStatus 函數的可能外部方法定義：   [DllImport("Advapi32.dll", CharSet=CharSet.Auto)] static extern Boolean FileEncryptionStatus(String filename,    out UInt32 status);   該定義使用 out 關鍵字來為 UInt32 狀態值指示 by-ref 參數。這裡我也可以選擇 ref 關鍵字，實際上在運行時會產生相同的機器碼。out 關鍵字只是一個 by-ref 參數的規范，它向 C# 編譯器指示所傳遞的數據只在被調用的函數外部傳遞。相反，如果使用 ref 關鍵字，則編譯器會假定數據可以在被調用的函數的內部和外部傳遞。   托管代碼中 out 和 ref 參數的另一個很好的方面是，地址作為 by-ref 參數傳遞的變量可以是線程堆棧中的一個本地變量、一個類或結構的元素，也可以是具有合適數據類型的數組中的一個元素引用。調用程序的這種靈活性使得 by-ref 參數成為封送緩沖區指針以及單數值指針的一個很好的起點。只有在我發現 ref 或 out 參數不符合我的需要的情況下，我才會考慮將指針封送為更復雜的 CLR 類型（例如類或數組對象）。   如果您不熟悉 C 語法或者調用 Windows API 函數，有時很難知道一個方法參數是否需要指針。一個常見的指示符是看參數類型是否是以字母 P 或 LP 開頭的，例如 LPDWord 或 PINT。在這兩個例子中，LP 和 P 指示參數是一個指針，而它們指向的數據類型分別為 DWord 或 INT。然而，在有些情況下，可以直接使用 C 語言語法中的星號 (*) 將 API 函數定義為指針。以下代碼片段展示了這方面的示例：   void TakesAPointer(DWord* pNum);   可以看到，上述函數的唯一一個參數是指向 DWord 變量的指針。   當通過 P/Invoke 封送指針時，ref 和 out 只用於托管代碼中的值類型。當一個參數的 CLR 類型使用 struct 關鍵字定義時，可以認為該參數是一個值類型。Out 和 ref 用於封送指向這些數據類型的指針，因為通常值類型變量是對象或數據，而在托管代碼中並沒有對值類型的引用。相反，當封送引用類型對象時，並不需要 ref 和 out 關鍵字，因為變量已經是對象的引用了。   如果您對引用類型和值類型之間的差別不是很熟悉，請查閱 2000 年 12 月 發行的 MSDN? Magazine，在 .Net 專欄的主題中可以找到更多信息。大多數 CLR 類型都是引用類型；然而，除了 System.String 和 System.Object，所有的基元類型（例如 System.Int32 和 System.Boolean）都是值類型。   封送不透明 (Opaque) 指針：一種特殊情況   有時在 Windows API 中，方法傳遞或返回的指針是不透明的，這意味著該指針值從技術角度講是一個指針，但代碼卻不直接使用它。相反，代碼將該指針返回給 Windows 以便隨後進行重用。   一個非常常見的例子就是句柄的概念。在 Windows 中，內部數據結構（從文件到屏幕上的按鈕）在應用程序代碼中都表示為句柄。句柄其實就是不透明的指針或有著指針寬度的數值，應用程序用它來表示內部的 OS 構造。   少數情況下，API 函數也將不透明指針定義為 PVOID 或 LPVOID 類型。在 Windows API 的定義中，這些類型意思就是說該指針沒有類型。   當一個不透明指針返回給您的應用程序（或者您的應用程序期望得到一個不透明指針）時，您應該將參數或返回值封送為 CLR 中的一種特殊類型 — System.IntPtr。當您使用 IntPtr 類型時，通常不使用 out 或 ref 參數，因為 IntPtr 意為直接持有指針。不過，如果您將一個指針封送為一個指針，則對 IntPtr 使用 by-ref 參數是合適的。   在 CLR 類型系統中，System.IntPtr 類型有一個特殊的屬性。不像系統中的其他基類型，IntPtr 並沒有固定的大小。相反，它在運行時的大小是依底層操作系統的正常指針大小而定的。這意味著在 32 位的 Windows 中，IntPtr 變量的寬度是 32 位的，而在 64 位的 Windows 中，實時編譯器編譯的代碼會將 IntPtr 值看作 64 位的值。當在托管代碼和非托管代碼之間封送不透明指針時，這種自動, 調節大小的特點十分有用。   請記住，任何返回或接受句柄的 API 函數其實操作的就是不透明指針。您的代碼應該將 Windows 中的句柄封送成 System.IntPtr 值。   您可以在托管代碼中將 IntPtr 值強制轉換為 32 位或 64 位的整數值，或將後者強制轉換為前者。然而，當使用 Windows API 函數時，因為指針應是不透明的，所以除了存儲和傳遞給外部方法外，不能將它們另做它用。這種“只限存儲和傳遞”規則的兩個特例是當您需要向外部方法傳遞 null 指針值和需要比較 IntPtr 值與 null 值的情況。為了做到這一點，您不能將零強制轉換為 System.IntPtr，而應該在 IntPtr 類型上使用 Int32.Zero 靜態公共字段，以便獲得用於比較或賦值的 null 值。   封送文本   在編程時經常要對文本數據進行處理。文本為 interop 制造了一些麻煩，這有兩個原因。首先，底層操作系統可能使用 Unicode 來表示字符串，也可能使用 ANSI。在極少數情況下，例如 MultiByteToWideChar API 函數的兩個參數在字符集上是不一致的。   第二個原因是，當需要進行 P/Invoke 時，要處理文本還需要特別了解到 C 和 CLR 處理文本的方式是不同的。在 C 中，字符串實際上只是一個字符值數組，通常以 null 作為結束符。大多數 Windows API 函數是按照以下條件處理字符串的：對於 ANSI，將其作為字符值數組；對於 Unicode，將其作為寬字符值數組。   幸運的是，CLR 被設計得相當靈活，當封送文本時問題得以輕松解決，而不用在意 Windows API 函數期望從您的應用程序得到的是什麼。這裡是一些需要記住的主要考慮事項：   ? 是您的應用程序向 API 函數傳遞文本數據，還是 API 函數向您的應用程序返回字符串數據？或者二者兼有？   ? 您的外部方法應該使用什麼托管類型？   ? API 函數期望得到的是什麼格式的非托管字符串？     我們首先解答最後一個問題。大多數 Windows API 函數都帶有 LPTSTR 或 LPCTSTR 值。（從函數角度看）它們分別是可修改和不可修改的緩沖區，包含以 null 結束的字符數組。“C”代表常數，意味著使用該參數信息不會傳遞到函數外部。LPTSTR 中的“T”表明該參數可以是 Unicode 或 ANSI，取決於您選擇的字符集和底層操作系統的字符集。因為在 Windows API 中大多數字符串參數都是這兩種類型之一，所以只要在 DllImportAttribute 中選擇 CharSet.Auto，CLR 就按默認的方式工作。   然而，有些 API 函數或自定義的 DLL 函數采用不同的方式表示字符串。如果您要用到一個這樣的函數，就可以采用 MarshalAsAttribute 修飾外部方法的字符串參數，並指明一種不同於默認 LPTSTR 的字符串格式。有關 MarshalAsAttribute 的更多信息，請參閱位於 MarshalAsAttribute Class 的 Platform SDK 文檔主題。   現在讓我們看一下字符串信息在您的代碼和非托管函數之間傳遞的方向。有兩種方式可以知道處理字符串時信息的傳遞方向。第一個也是最可靠的一個方法就是首先理解參數的用途。例如，您正調用一個參數，它的名稱類似 CreateMutex 並帶有一個字符串，則可以想像該字符串信息是從應用程序向 API 函數傳遞的。同時，如果您調用 GetUserName，則該函數的名稱表明字符串信息是從該函數向您的應用程序傳遞的。   除了這種比較合理的方法外，第二種查找信息傳遞方向的方式就是查找 API 參數類型中的字母“C”。例如，GetUserName API 函數的第一個參數被定義為 LPTSTR 類型，它代表一個指向 Unicode 或 ANSI 字符串緩沖區的長指針。但是 CreateMutex 的名稱參數被類型化為 LTCTSTR。請注意，這裡的類型定義是一樣的，但增加一個字母“C”來表明緩沖區為常數，API 函數不能寫入。   一旦明確了文本參數是只用作輸入還是用作輸入/輸出，就可以確定使用哪種 CLR 類型作為參數類型。這裡有一些規則。如果字符串參數只用作輸入，則使用 System.String 類型。在托管代碼中，字符串是不變的，適合用於不會被本機 API 函數更改的緩沖區。   如果字符串參數可以用作輸入和/或輸出，則使用 System.StringBuilder 類型。StringBuilder 類型是一個很有用的類庫類型，它可以幫助您有效地構建字符串，也正好可以將緩沖區傳遞給本機函數，由本機函數為您填充字符串數據。一旦函數調用返回，您只需要調用 StringBuilder 對象的 ToString 就可以得到一個 String 對象。   GetShortPathName API 函數能很好地用於顯示什麼時候使用 String、什麼時候使用 StringBuilder，因為它只帶有三個參數：一個輸入字符串、一個輸出字符串和一個指明輸出緩沖區的字符長度的參數。   圖 3 所示為加注釋的非托管 GetShortPathName 函數文檔，它同時指出了輸入和輸出字符串參數。它引出了托管的外部方法定義，也如圖 3 所示。請注意第一個參數被封送為 System.String，因為它是一個只用作輸入的參數。第二個參數代表一個輸出緩沖區，它使用了 System.StringBuilder。   小結   本月專欄所介紹的 P/Invoke 功能足夠調用 Windows 中的許多 API 函數。然而，如果您大量用到 interop，則會最終發現自己封送了很復雜的數據結構，甚至可能需要在托管代碼中通過指針直接訪問內存。實際上，本機代碼中的 interop 可以是一個將細節和低級比特藏在裡面的真正的潘多拉盒子。CLR、C# 和托管 C++ 提供了許多有用的功能；也許以後我會在本專欄介紹高級的 P/Invoke 話題。   同時，只要您覺得 .Net Framework 類庫無法播放您的聲音或者為您執行其他一些功能，您可以知道如何向原始而優秀的 Windows API 尋求一些幫助。   API(應用編程接口)是程序與處理器接口的命令集。最常用的就是在外部調用微軟Windows內部的進程。Windows API包括成千的你可以使用的函數、結構、常量。這些函數是用C語言寫的，在使用他們之前，你必須聲明。 定義Dll的進程將相當的復雜，甚至比VB還復雜。你可以使用API VIEwer工具得到API函數的聲明，但是必須注意的是，它的參數類型跟C#的不一樣。 大部分的高級語言都支持API，微軟函數類庫(MFC)封裝了大部分的Win32 API。ODBC API對提高數據庫的操作速度大有好處。使用API，可以請求更底層的系統服務。API從簡單的對話框到復雜的加密運算都提供支持。開發者應該知道如何在他們程序中使用API API有許多類型，（針對不同的操作系統、處理器…………） OS specific API: 操作系統特有API: 每種操作系統都有一套公用API和專有API。比如：Windows NT 支持MS-DOS, Win16, Win32, POSIX (便攜式操作系統接口)，OS/2 console API ；同時Windows 95 supports MS-DOS, Win16 和Win32 API。 Win16 和 Win32 API: WIN16 是基於16位的處理器，並使用16位的值，它是一個獨立的平台。比如：你可以運行TSR 程序在MS-DOS環境下。 WIN32 是基於32位的處理器，並使用32位的值。他可用於任何操作系統，它的使用范圍更廣。 Win32 API has 32 prefix after the library name e.g. KERNEL32, USER32 etc? Win32 API的DLL一般都具有32的後綴，比如：KERNEL32, USER32等。 所有的API都在下面3個DLL中實現的。 Kernel User GDI 1. KERNEL 它的庫名是：KERNEL32.DLL，它是操作系統管理的API集 Process loading. 加載進程 Context switching. File I/O. 文件操作 Memory management. 內存管理 比如：GlobalMemoryStatus 函數獲得目前系統物理虛擬內存的使用信息。 2. USER 在WIN32下，它的庫名是 USER32.DLL This allows managing the entire user interfaces such as 它管理全部的用戶界面，比如： Windows 窗口 Menus 菜單 Dialog Boxes 對話框 Icons etc., 圖標等 比如：DrawIcon 畫一個圖標在指定的設備上。 3. GDI (Graphical Device Interface) 這個DLL是GDI32.dll，它負責圖像的輸出，使用GDI繪出窗口，菜單，對話框 It can create Graphical Output. 輸出圖像 比如：CreateBitmap 函數創建一個指定寬度、高度和顏色格式的位圖。 C#中API的工具對初學者是相當不錯的。在C#使用中使用API之前，你應該先知道C#中如何使用結構、類型轉換，安全與不安全代碼等。 使用復雜的api之前，我們先用一個簡單的MessageBox API作為列子。打開一個C#工程，增加一個按鈕，在按鈕的點擊事件中，我們將顯示一個信息框。 增加使用外部庫的命名空間： using System.Runtime.InteropServices; 下面聲明API [DllImport("User32.dll")] DllImport屬性用來指定包含外部方法的動態連接庫的位置。 "User32.dll"指出了庫名，static 指明它不屬於特定的對象。extern 指明是一個外部的方法。帶有DllImport 屬性的方法必須帶有修飾符extern 。 MessageBox 是一個漢數名，帶四個參數返回一個int型值。 許多API使用結構來傳遞、返回參數，這樣可以減少復雜度。它也允許使用象MessageBox 函數那樣，使用固定的參數。   在按鈕的點擊事件中增加下面代碼： protected void button1_Click (object sender, System.EventArgs e) { MessageBox (0,"API Message Box","API Demo",0); } 編譯並運行程序，點擊按鈕以後，你就可以看到一個由API調用的信息框。 Using structure 使用結構 API中經常使用復雜的結構。不過一旦你明白了他們，將是很簡單的。 In next example we will use GetSystemInfo API which returns information about the current system. 下面的列子，我們用GetSystemInfo API得到當前系統的信息。 第一步：增加一個C#窗口，並在上面增加一個按鈕，在窗口代碼頁增加一個命名空間： using System.Runtime.InteropServices; 聲明 GetSystemInfo 的參數結構: [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } 聲明API函數： [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ref是一個標志參量傳遞形式的關鍵字，它使傳入傳出的變量指向同一個變量（傳址傳遞） 在按鈕點擊事件中增加下面的代碼， protected void button1_Click (object sender, System.EventArgs e) { try { SYSTEM_INFO pSI = new SYSTEM_INFO(); GetSystemInfo(ref pSI); Once you retrIEve the structure perform Operations on required parameter 比如： listBox1.Items.Insert(0,pSI.dwActiveProcessorMask.ToString()); } catch(Exception er) { MessageBox.Show (er.Message); } }     用Visual C#調用Windows API函數   北京機械工業學院研00級（100085）冉林倉        Api函數是構築Windws應用程序的基石，每一種Windows應用程序開發工具，它提供的底層函數都間接或直接地調用了Windows API函數，同時為了實現功能擴展，一般也都提供了調用WindowsAPI函數的接口， 也就是說具備調用動態連接庫的能力。Visual C#和其它開發工具一樣也能夠調用動態鏈接庫的API函數。.Net框架本身提供了這樣一種服務,允許受管轄的代碼調用動態鏈接庫中實現的非受管轄函數,包括操作系統提供的Windows API函數。它能夠定位和調用輸出函數,根據需要，組織其各個參數(整型、字符串類型、數組、和結構等等)跨越互操作邊界。   下面以C#為例簡單介紹調用API的基本過程：  動態鏈接庫函數的聲明  　動態鏈接庫函數使用前必須聲明，相對於VB,C#函數聲明顯得更加羅嗦，前者通過 Api VIEwer粘貼以後，可以直接使用，而後者則需要對參數作些額外的變化工作。   　動態鏈接庫函數聲明部分一般由下列兩部分組成，一是函數名或索引號，二是動態鏈接庫的文件名。  　 譬如，你想調用User32.DLL中的MessageBox函數，我們必須指明函數的名字MessageBoxA或MessageBoxW，以及庫名字User32.dll,我們知道Win32 API對每一個涉及字符串和字符的函數一般都存在兩個版本，單字節字符的ANSI版本和雙字節字符的UNICODE版本。   　下面是一個調用API函數的例子：  [DllImport("KERNEL32.DLL", EntryPoint="MoveFileW", SetLastError=true,  CharSet=CharSet.Unicode, ExactSpelling=true,  CallingConvention=CallingConvention.StdCall)]  public static extern bool MoveFile(String src, String dst);    　其中入口點EntryPoint標識函數在動態鏈接庫的入口位置，在一個受管轄的工程中，目標函數的原始名字和序號入口點不僅標識一個跨越互操作界限的函數。而且，你還可以把這個入口點映射為一個不同的名字，也就是對函數進行重命名。重命名可以給調用函數帶來種種便利，通過重命名，一方面我們不用為函數的大小寫傷透腦筋，同時它也可以保證與已有的命名規則保持一致，允許帶有不同參數類型的函數共存，更重要的是它簡化了對ANSI和Unicode版本的調用。CharSet用於標識函數調用所采用的是Unicode或是ANSI版本，ExactSpelling＝false將告訴編譯器,讓編譯器決定使用Unicode或者是Ansi版本。其它的參數請參考MSDN在線幫助.   　在C#中，你可以在EntryPoint域通過名字和序號聲明一個動態鏈接庫函數，如果在方法定義中使用的函數名與DLL入口點相同，你不需要在EntryPoint域顯示聲明函數。否則，你必須使用下列屬性格式指示一個名字和序號。   [DllImport("dllname", EntryPoint="Functionname")]  [DllImport("dllname", EntryPoint="#123")]  值得注意的是，你必須在數字序號前加“＃”  下面是一個用MsgBox替換MessageBox名字的例子：  [C#]  using System.Runtime.InteropServices;    public class Win32 {  [DllImport("user32.dll", EntryPoint="MessageBox")]  public static extern int MsgBox(int hWnd, String text, String caption, uint type);  }  許多受管轄的動態鏈接庫函數期望你能夠傳遞一個復雜的參數類型給函數，譬如一個用戶定義的結構類型成員或者受管轄代碼定義的一個類成員，這時你必須提供額外的信息格式化這個類型，以保持參數原有的布局和對齊。   C#提供了一個StructLayoutAttribute類，通過它你可以定義自己的格式化類型，在受管轄代碼中，格式化類型是一個用StructLayoutAttribute說明的結構或類成員，通過它能夠保證其內部成員預期的布局信息。布局的選項共有三種：   布局選項  描述  LayoutKind.Automatic  為了提高效率允許運行態對類型成員重新排序。  注意：永遠不要使用這個選項來調用不受管轄的動態鏈接庫函數。  LayoutKind.Explicit  對每個域按照FIEldOffset屬性對類型成員排序  LayoutKind.Sequential  對出現在受管轄類型定義地方的不受管轄內存中的類型成員進行排序。  傳遞結構成員  下面的例子說明如何在受管轄代碼中定義一個點和矩形類型，並作為一個參數傳遞給User32.dll庫中的PtInRect函數，  函數的不受管轄原型聲明如下：  BOOL PtInRect(const RECT *lprc, POINT pt);  注意你必須通過引用傳遞Rect結構參數，因為函數需要一個Rect的結構指針。  [C#]  using System.Runtime.InteropServices;    [StructLayout(LayoutKind.Sequential)]  public struct Point {  public int x;  public int y;  }    [StructLayout(LayoutKind.Explicit]  public struct Rect {  [FIEldOffset(0)] public int left;  [FIEldOffset(4)] public int top;  [FIEldOffset(8)] public int right;  [FIEldOffset(12)] public int bottom;  }    class Win32API {  [DllImport("User32.dll")]  public static extern Bool PtInRect(ref Rect r, Point p);  }  類似你可以調用GetSystemInfo函數獲得系統信息：  ? using System.Runtime.InteropServices;  [StructLayout(LayoutKind.Sequential)]  public struct SYSTEM_INFO {  public uint dwOemId;  public uint dwPageSize;  public uint lpMinimumApplicationAddress;  public uint lpMaximumApplicationAddress;  public uint dwActiveProcessorMask;  public uint dwNumberOfProcessors;  public uint dwProcessorType;  public uint dwAllocationGranularity;  public uint dwProcessorLevel;  public uint dwProcessorRevision;  }          [DllImport("kernel32")]  static extern void GetSystemInfo(ref SYSTEM_INFO pSI);    SYSTEM_INFO pSI = new SYSTEM_INFO();  GetSystemInfo(ref pSI);    類成員的傳遞  同樣只要類具有一個固定的類成員布局，你也可以傳遞一個類成員給一個不受管轄的動態鏈接庫函數，下面的例子主要說明如何傳遞一個sequential順序定義的MySystemTime類給User32.dll的GetSystemTime函數, 函數用C/C++調用規范如下:   void GetSystemTime(SYSTEMTIME* SystemTime);  不像傳值類型,類總是通過引用傳遞參數.  [C#]  [StructLayout(LayoutKind.Sequential)]  public class MySystemTime {  public ushort wYear;  public ushort wMonth;  public ushort wDayOfWeek;  public ushort wDay;  public ushort wHour;  public ushort wMinute;  public ushort wSecond;  public ushort wMilliseconds;  }  class Win32API {  [DllImport("User32.dll")]  public static extern void GetSystemTime(MySystemTime st);  }  回調函數的傳遞:  從受管轄的代碼中調用大多數動態鏈接庫函數,你只需創建一個受管轄的函數定義，然後調用它即可,這個過程非常直接。  如果一個動態鏈接庫函數需要一個函數指針作為參數，你還需要做以下幾步：  首先，你必須參考有關這個函數的文檔，確定這個函數是否需要一個回調；第二，你必須在受管轄代碼中創建一個回調函數；最後，你可以把指向這個函數的指針作為一個參數創遞給DLL函數,.   回調函數及其實現:  回調函數經常用在任務需要重復執行的場合,譬如用於枚舉函數,譬如Win32 API 中的EnumFontFamilIEs(字體枚舉), EnumPrinters(打印機), EnumWindows (窗口枚舉)函數. 下面以窗口枚舉為例,談談如何通過調用EnumWindow 函數遍歷系統中存在的所有窗口   分下面幾個步驟:  1. 在實現調用前先參考函數的聲明  BOOL EnumWindows(WNDENUMPROC lpEnumFunc, LPARMAM IParam)  顯然這個函數需要一個回調函數地址作為參數.  2. 創建一個受管轄的回調函數,這個例子聲明為代表類型(delegate),也就是我們所說的回調,它帶有兩個參數hwnd和lparam,第一個參數是一個窗口句柄，第二個參數由應用程序定義，兩個參數均為整形。   　　當這個回調函數返回一個非零值時，標示執行成功，零則暗示失敗，這個例子總是返回True值，以便持續枚舉。  3. 最後創建以代表對象(delegate)，並把它作為一個參數傳遞給EnumWindows 函數，平台會自動地 把代表轉化成函數能夠識別的回調格式。   [C#]  using System;  using System.Runtime.InteropServices;    public delegate bool CallBack(int hwnd, int lParam);    public class EnumReportApp {    [DllImport("user32")]  public static extern int EnumWindows(CallBack x, int y);    public static void Main()  {  CallBack myCallBack = new CallBack(EnumReportApp.Report);  EnumWindows(myCallBack, 0);  }    public static bool Report(int hwnd, int lParam) {  Console.Write("窗口句柄為");  Console.WriteLine(hwnd);  return true;  }  }    指針類型參數傳遞：  　在Windows API函數調用時，大部分函數采用指針傳遞參數，對一個結構變量指針，我們除了使用上面的類和結構方法傳遞參數之外，我們有時還可以采用數組傳遞參數。   　下面這個函數通過調用GetUserName獲得用戶名  BOOL GetUserName(  LPTSTR lpBuffer, // 用戶名緩沖區  LPDWord nSize // 存放緩沖區大小的地址指針  );  　  [DllImport("Advapi32.dll",  EntryPoint="GetComputerName",  ExactSpelling=false,  SetLastError=true)]  static extern bool GetComputerName (  [MarshalAs(UnmanagedType.LPArray)] byte[] lpBuffer,  　 [MarshalAs(UnmanagedType.LPArray)] Int32[] nSize );  　這個函數接受兩個參數，char * 和int *,因為你必須分配一個字符串緩沖區以接受字符串指針，你可以使用String類代替這個參數類型，當然你還可以聲明一個字節數組傳遞ANSI字符串，同樣你也可以聲明一個只有一個元素的長整型數組，使用數組名作為第二個參數。上面的函數可以調用如下：   byte[] str=new byte[20];  Int32[] len=new Int32[1];  len[0]=20;  GetComputerName (str,len);  MessageBox.Show(System.Text.Encoding.ASCII.GetString(str));  　最後需要提醒的是，每一種方法使用前必須在文件頭加上：  　using System.Runtime.InteropServices;