如何在C#中使用Win32和其他庫之三

具有內嵌字符數組的結構

某些函數接受具有內嵌字符數組的結構。例如，GetTimeZoneInformation() 函數接受指向以下結構的指針：

typedef struct _TIME_ZONE_INFORMATION {     LONG       Bias;     WCHAR      StandardName[ 32 ];     SYSTEMTIME StandardDate;     LONG       StandardBias;     WCHAR      DaylightName[ 32 ];     SYSTEMTIME DaylightDate;     LONG       DaylightBias; } TIME_ZONE_INFORMATION, *PTIME_ZONE_INFORMATION;

在 C# 中使用它需要有兩種結構。一種是 SYSTEMTIME，它的設置很簡單：

   struct SystemTime   {      public short wYear;      public short wMonth;      public short wDayOfWeek;      public short wDay;      public short wHour;      public short wMinute;      public short wSecond;      public short wMilliseconds;   }

這里沒有什么特別之處；另一種是 TimeZoneInformation，它的定義要復雜一些：

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]struct TimeZoneInformation{    public int bias;   [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]   public string standardName;   SystemTime standardDate;   public int standardBias;   [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]   public string daylightName;   SystemTime daylightDate;   public int daylightBias;}

此定義有兩個重要的細節。第一個是 MarshalAs 屬性：

   [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]

查看 ByValTStr 的文檔，我們發現該屬性用于內嵌的字符數組；另一個是 SizeConst，它用于設置數組的大小。

我在第一次編寫這段代碼時，遇到了執行引擎錯誤。通常這意味著部分互操作覆蓋了某些內存，表明結構的大小存在錯誤。我使用 Marshal.SizeOf() 來獲取所使用的封送拆收器的大小，結果是 108 字節。我進一步進行了調查，很快回憶起用于互操作的默認字符類型是 Ansi 或單字節。而函數定義中的字符類型為 WCHAR，是雙字節，因此導致了這一問題。

我通過添加 StructLayout 屬性進行了更正。結構在默認情況下按順序布局，這意味著所有字段都將以它們列出的順序排列。CharSet 的值被設置為 Unicode，以便始終使用正確的字符類型。

經過這樣處理后，該函數一切正常。您可能想知道我為什么不在此函數中使用 CharSet.Auto。這是因為，它也沒有 A 和 W 變體，而始終使用 Unicode 字符串，因此我采用了上述方法編碼。

具有回調的函數

當 Win32 函數需要返回多項數據時，通常都是通過回調機制來實現的。開發人員將函數指針傳遞給函數，然后針對每一項調用開發人員的函數。

在 C# 中沒有函數指針，而是使用“委托”，在調用 Win32 函數時使用委托來代替函數指針。

EnumDesktops() 函數就是這類函數的一個示例：

BOOL EnumDesktops(  HWINSTA hwinsta,            // 窗口實例的句柄  DESKTOPENUMPROC lpEnumFunc, // 回調函數  LPARAM lParam               // 用于回調函數的值);

HWINSTA 類型由 IntPtr 代替，而 LPARAM 由 int 代替。DESKTOPENUMPROC 所需的工作要多一些。下面是 MSDN 中的定義：

BOOL CALLBACK EnumDesktopProc(  LPTSTR lpszDesktop,  // 桌面名稱  LPARAM lParam        // 用戶定義的值);

我們可以將它轉換為以下委托：

delegate bool EnumDesktopProc(   [MarshalAs(UnmanagedType.LPTStr)]   string desktopName,   int lParam);

完成該定義后，我們可以為 EnumDesktops() 編寫以下定義：

[DllImport("user32.dll", CharSet = CharSet.Auto)]static extern bool EnumDesktops(   IntPtr windowStation,   EnumDesktopProc callback,   int lParam);

這樣該函數就可以正常運行了。

在互操作中使用委托時有個很重要的技巧：封送拆收器創建了指向委托的函數指針，該函數指針被傳遞給非托管函數。但是，封送拆收器無法確定非托管函數要使用函數指針做些什么，因此它假定函數指針只需在調用該函數時有效即可。

結果是如果您調用諸如 SetConsoleCtrlHandler() 這樣的函數，其中的函數指針將被保存以便將來使用，您就需要確保在您的代碼中引用委托。如果不這樣做，函數可能表面上能執行，但在將來的內存回收處理中會刪除委托，并且會出現錯誤。

其他高級函數

迄今為止我列出的示例都比較簡單，但是還有很多更復雜的 Win32 函數。下面是一個示例：

DWORD SetEntriesInAcl(  ULONG cCountOfExplicitEntries,           // 項數  PEXPLICIT_ACCESS pListOfExplicitEntries, // 緩沖區  PACL OldAcl,                             // 原始 ACL  PACL *NewAcl                             // 新 ACL);

前兩個參數的處理比較簡單：ulong 很簡單，并且可以使用 UnmanagedType.LPArray 來封送緩沖區。

但第三和第四個參數有一些問題。問題在于定義 ACL 的方式。ACL 結構僅定義了 ACL 標頭，而緩沖區的其余部分由 ACE 組成。ACE 可以具有多種不同類型，并且這些不同類型的 ACE 的長度也不同。

如果您愿意為所有緩沖區分配空間，并且愿意使用不太安全的代碼，則可以用 C# 進行處理。但工作量很大，并且程序非常難調試。而使用 C++ 處理此 API 就容易得多。