warewing

句柄的本质  
  一、书上定义：  
   
  <<Microsoft   Windows   3   Developer''s   Workshop>>(Microsoft   Press,by   Richard   Wilton)  
 在Windows环境中，句柄是用来标识项目的，这些项目包括：模块(module)、任务(task)、实例   (instance)、文件(file)、内存块(block   of   memory)、菜单(menu)、控制(control)、 字体(font)、资源(resource)，包括图标(icon)，光标   (cursor)，字符串(string)等、GDI对象(GDI   object)，包括位图(bitmap)，画刷(brush)，元文件（metafile）,调色板(palette)，画笔(pen)，区域   (region)，以及设备描述表(device   context)。  
   
  <<WINDOWS编程短平快>>(南京大学出版社)：  
          句柄是WONDOWS用来标识被应用程序所建立或使用的对象的唯一整数，WINDOWS使用各种各样的句柄标识诸如应用程序实例，窗口，控制，位图，GDI对象等等。WINDOWS句柄有点象C语言中的文件句柄。  
   
  二、MFC源代码：  
   
  #ifdef   STRICT  
  typedef   void   *HANDLE;  
  #define   DECLARE_HANDLE(name)   struct   name##__   {   int   unused;   };   typedef   struct   name##__   *name  
  #else  
  typedef   PVOID   HANDLE;  
  #define   DECLARE_HANDLE(name)   typedef   HANDLE   name  
  #endif  
   
  DECLARE_HANDLE(HMODULE);  
  DECLARE_HANDLE(HINSTANCE);  
  DECLARE_HANDLE(HLOCAL);  
  DECLARE_HANDLE(HGLOBAL);  
  DECLARE_HANDLE(HDC);  
  DECLARE_HANDLE(HRGN);  
  DECLARE_HANDLE(HWND);  
  DECLARE_HANDLE(HMENU);  
  DECLARE_HANDLE(HACCEL);  
  DECLARE_HANDLE(HTASK);  
   
   
  三、理解：  
          HANDLE就是PVOID，也就是无类型指针，  
          上面这些资源的句柄Handles都不过是指向struct的指针，至于这个struct的用处，连M$都说unused了，现在解释下M$这么做的意 义，这就是所谓数据封装，你可以在你的程序中把M$的内部结构指针传来传去，可是你却不知道它到底指向的内容是什么。  
   
          句柄与指针确实是完全不同的两个概念。句柄仅仅是一个32位整数，WIN32中用于标记某个系统或进程的对象，可以理解为对象索引（由于M$未完全公开相 关技术，在一定程度上只能如此理解），这个索引更像是一种映射关系（从句柄到对象指针的映射），而不是纯粹意义上的“数组下标”。  
   
   
            句柄可以理解为用于指向或标识内存的一块“资源”，这些资源如：文件(file)、内存块(block   of   memory)、菜单(menu)等等。操作系统通过句柄来定位核心对象和系统资源。  
          指针即为指向内存的“数据或指令”某一单元。  
   
 说的确切一点，句柄实际上是一种指向某种资源的指针，但与指针又有所不同：指针对应着一个数据在内存中的地址，得到了指针就可以自由地修改该数据。Windows并不希望一般程序修改其内部数据结构，因为这样太不安全。所以Windows给每个使用GlobalAlloc等函数声明的内存区域指定一个句柄(本质上仍是一个指针，但不要直接操作它)，平时你只是在调用API函数时利用这个句柄来说明要操作哪段内存。  
   
           
  四、引喻：  
        牧童遥指杏花村  
        牧童的手为指针，杏花村的牌子为句柄，杏花村酒店为对象的实例.  
   
   
  附注：获得窗口句柄三种方法  
   
  1.HWND   FindWindow(LPCTSTR   lpClassName,   LPCTSTR   lpWindowName)  
   
        HWND   FindWindowEx(HWND   hwndParent,   HWND   hwndChildAfter,LPCTSTR   lpClassName,   LPCTSTR   lpWindowName)  
   
  2.HWND   WindowFromPoint(POINT&   Point)//获得当前鼠标光标位置的窗口HWND  
   
  3.BOOL   CALLBACK   EnumChildProc(HWND   hwnd,LPARAM   lParam)  
   
        BOOL   CALLBACK   EnumChildWindows(HWND   hWndParent,   WNDENUMPROC   lpEnumFunc,LPARAM   lParam)  
   
        BOOL   CALLBACK   EnumWindows(WNDENUMPROC   lpEnumFunc,   LPARAM   lParam)  
   
        BOOL   CALLBACK   EnumWindowsProc(HWND   hwnd,   LPARAM   lParam)

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;

最近,真的發生了很多事情!從國家大事,到自己身邊到影響自己到事情,真的很煩,很苦惱!~
五月,真是多事之秋,我和我女朋友分手到季節...我不記得,什麽時候認識的,我只記得第一次正式見面是找了個接口在玄武湖畔,她束者兩個大麻花辮子,咋一看,好像是村姑,老實說,真的不是我喜歡大那種比較活潑,好動大女孩,不過她,有她大恬靜,快樂!直到我失去大時候才真的體會到她到好...我總是很遲鈍,對在身邊對人,不懂得珍惜,失去了,才知道珍貴!
最近這幾天,常常做夢,夢到她,回憶我們在一起對日子,真是別有滋味和樂趣,雖然新街口沒什麽好玩都,但是我們一逛就是一整天,直到自己走不動了,辦的年卡,也是,去過很多公園...可惜..在最後時刻,我們分開了,太不能接受了!!!
現在又跟一個小MM玩,以前我喜歡過的,但是現在卻沒有那種强烈的感覺了,倒是懷念起我的女朋友了,哎...人生真無趣,老實被耍,別別人耍,痛苦..傷心!悲哀..
看不到希望,之是按照自己到計劃活動,計劃每天運動,計劃每周爬山,計劃靠試,每天按著規律去上班,按照規律下班,按照規律活動,按照規律吃飯,睡覺,無聊,乏味,上班盼休息,休息盼過年!跟上學沒什麽兩樣,
雖然按照我的理念,每天進步一點,積累起來就是一個大大進步,的確,實時卻不是這麽容易做到的!太多的事情去影響心情,音響自己的想法!很多事情,不是簡簡單單就可以實現的.需要很多元素綜合的觸發,實現一項計劃,有太多元素,每個元素都可以是不穩定因素!
羡慕,妒忌,憤怒,一切人類所擁有都情緒很快充滿了我的大腦,忘記了很多守則,秩序!我都不知道!
年青人呀~!   還是照計劃實施吧~!緣分..呵呵,來就來吧,不用去强求來!  

1、Array in stack

对于这样的struct：typedef struct { int XY[2]; } Point2D;

要在.NET为一个非托管函数传递这样一个结构体，原来得这样定义：

　　现在可以这么写（不过得用unsafe上下文）：

 
不过这个功能还非常有限，不知道是出于什么原因考虑，只允许在strcut里面定义这样的数组，并且只能使用bool, byte,  short, int, long, char, sbyte, ushort, uint, ulong, float和double这样的 primitive类型。

也可以把数组作为局部变量分配在堆栈上，只是语法不太一样，那就是stackalloc关键字：int* fib = stackalloc int[100];，也要unsafe上下文。这可以提高不少效率。这是.NET 1.x就有的功能，只是似乎没人用这个

PS. 对于只允许使用primitive类型，我认为是没道理的，最起码应该允许所有值类型的栈内数组。设计者们为啥这么考虑呢？怕堆栈溢出？据我测试.NET的堆栈空间也是1M左右，大部分情况下这么大的栈空间都被浪费了。

2、Function pointer as a return value

在.NET 1.x做P/Invoke时，对于那些回调函数，可以使用Delegate类型的参数作为函数指针传入。但有些非托管函数的返回值也是个函数指针，此时.NET 1.1变得无能为力，要调用这个函数，你得用native代码再写个包装，总之很麻烦。

.NET 2.0的System.Runtime.InteropServices.Marshal类为此需求新增了两个方法：

3、Marshal过程支持更多的类型

这是一个很细的问题，比如这样一个非托管struct：

　　对应到C#，你也许会这样写：

　　事实上这是不可行的。在.NET 1.x，结构体内嵌定长数组的类型必须是primitive类型，否则不能进行marshal过程。事实上调用Marshal.SizeOf时，会弹出异常说“无法得到大小”云云

.NET 2.0把这个问题给改了（与其说是个增强，还不如说是修正了这个bug），Marshal.SizeOf(typeof(Point2DX3))现在可以正常运行，输出24 == 3 * 2 * sizeof(int)。

让Marshal.SizeOf正常工作非常重要，得不到对象的大小，内存对齐都无法保证，marshal过程根本就不可行。

此外，正常工作的Marshal.SizeOf可以使这种“序列化”方式也总能正常工作（这在我以前的blog贴过，这里是Generic版本）：

和.NET内置的序列化机制相比，这个方案效率要高得多。和.NET内置的序列化机制相似，这里需要对象或结构体内部的所有成员都能使用 Marshal.SizeOf得到其大小，对应于“对象或结构体内部的所有成员都带有[Serializable]特性或者实现了 ISerializable接口”。

PS. 这个序列化方案效率虽高，但不如.NET内置的方案可靠。.NET的编译器可以检查一个 类型能否支持序列化，而这个方案得由程序员判断Marshal.SizeOf能否工作（比如Marshal.SizeOf绝对不会知道string类型实 际占用多少内存，也就是说类型实例的大小必须是固定的才行）。

　　简单字符串

下面是一个接受字符串参数的函数的简单示例： 

 

根路径定义为 LPCTSTR。这是独立于平台的字符串指针。 

由于不存在名为 GetDiskFreeSpace() 的函数，封送拆收器将自动查找“A”或“W”变体，并调用相应的函数。我们使用一个属性来告诉封送拆收器，API 所要求的字符串类型。 

以下是该函数的完整定义，就象我开始定义的那样： 

  

不幸的是，当我试图运行时，该函数不能执行。问题在于，无论我们在哪个平台上，封送拆收器在默认情况下都试图查找 API 的 Ansi 版本，由于  LPTStr 意味着在 Windows NT 平台上会使用 Unicode 字符串，因此试图用 Unicode 字符串来调用 Ansi 函数就 会失败。 

有两种方法可以解决这个问题：一种简单的方法是删除 MarshalAs 属性。如果这样做，将始终调用该函数的 A 版 本，如果在您所涉及的所有平台上都有这种版本，这是个很好的方法。但是，这会降低代码的执行速度，因为封送拆收器要将 .NET 字符串从  Unicode 转换为多字节，然后调用函数的 A 版本（将字符串转换回 Unicode），最后调用函数的 W 版本。 

要避免出现这种情况，您需要告诉封送拆收器，要它在 Win9x 平台上时查找 A 版本，而在 NT 平台上时查找 W 版本。要实现这一目的，可以将 CharSet 设置为 DllImport 属性的一部分： 

[DllImport("kernel32.dll", CharSet = CharSet.Auto)] 

在我的非正式计时测试中，我发现这一做法比前一种方法快了大约百分之五。 

对于大多数 Win32 API，都可以对字符串类型设置 CharSet 属性并使用 LPTStr。但是，还有一些不采用 A/W 机制的函数，对于这些函数必须采取不同的方法。

字符串缓冲区

.NET 中的字符串类型是不可改变的类型，这意味着它的值将永远保持不变。对于要将字符串值复制到字符串缓冲区的函数，字符串将无效。这样做至少会破 坏由封送拆收器在转换字符串时创建的临时缓冲区；严重时会破坏托管堆，而这通常会导致错误的发生。无论哪种情况都不可能获得正确的返回值。 

要解决此问题，我们需要使用其他类型。StringBuilder 类型就是被设计为用作缓冲区的，我们将使用它来代替字符串。下面是一个示例： 

  

使用此函数很简单： 

  

请注意，StringBuilder 的 Capacity 传递的是缓冲区大小。 

具有内嵌字符数组的结构

某些函数接受具有内嵌字符数组的结构。例如，GetTimeZoneInformation() 函数接受指向以下结构的指针： 

  

在 C# 中使用它需要有两种结构。一种是 SYSTEMTIME，它的设置很简单： 



这里没有什么特别之处；另一种是 TimeZoneInformation，它的定义要复杂一些： 


此定义有两个重要的细节。第一个是 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() 函数就是这类函数的一个示例：



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



我们可以将它转换为以下委托：



完成该定义后，我们可以为 EnumDesktops() 编写以下定义：



这样该函数就可以正常运行了。

在互操作中使用委托时有个很重要的技巧：封送拆收器创建了指向委托的函数指针，该函数指针被传递给非托管函数。但是，封送拆收器无法确定非托管函数要使用函数指针做些什么，因此它假定函数指针只需在调用该函数时有效即可。

结果是如果您调用诸如 SetConsoleCtrlHandler() 这样的函数，其中的函数指针将被保存以便将来使用，您就需要确保在您的代码中引用委托。如果不这样做，函数可能表面上能执行，但在将来的内存回收处理中会删除委托，并且会出现错误。

其他高级函数

迄今为止我列出的示例都比较简单，但是还有很多更复杂的 Win32 函数。下面是一个示例：



前两个参数的处理比较简单：ulong 很简单，并且可以使用 UnmanagedType.LPArray 来封送缓冲区。

但第三和第四个参数有一些问题。问题在于定义 ACL 的方式。ACL 结构仅定义了 ACL 标头，而缓冲区的其余部分由 ACE 组成。ACE 可以具有多种不同类型，并且这些不同类型的 ACE 的长度也不同。

如果您愿意为所有缓冲区分配空间，并且愿意使用不太安全的代码，则可以用 C# 进行处理。但工作量很大，并且程序非常难调试。而使用 C++ 处理此 API 就容易得多。

属性的其他选项

DLLImport 和 StructLayout 属性具有一些非常有用的选项，有助于 P/Invoke 的使用。下面列出了所有这些选项：

DLLImport

CallingConvention

您可以用它来告诉封送拆收器，函数使用了哪些调用约定。您可以将它设置为您的函数的调用约定。通常，如果此设置错误，代码将不能执行。但是，如果您的函 数是 Cdecl 函数，并且使用 StdCall（默认）来调用该函数，那么函数能够执行，但函数参数不会从堆栈中删除，这会导致堆栈被填满。

CharSet

控制调用 A 变体还是调用 W 变体。

EntryPoint

此属性用于设置封送拆收器在 DLL 中查找的名称。设置此属性后，您可以将 C# 函数重新命名为任何名称。

ExactSpelling

将此属性设置为 true，封送拆收器将关闭 A 和 W 的查找特性。

PreserveSig

COM 互操作使得具有最终输出参数的函数看起来是由它返回的该值。此属性用于关闭这一特性。

SetLastError

确保调用 Win32 API SetLastError()，以便您找出发生的错误。

StructLayout

LayoutKind

结构在默认情况下按顺序布局，并且在多数情况下都适用。如果需要完全控制结构成员所放置的位置，可以使用 LayoutKind.Explicit，然后为每个结构成员添加 FieldOffset 属性。当您需要创建 union 时，通常需要这样做。

CharSet

控制 ByValTStr 成员的默认字符类型。

Pack

设置结构的压缩大小。它控制结构的排列方式。如果 C 结构采用了其他压缩方式，您可能需要设置此属性。

Size

设置结构大小。不常用；但是如果需要在结构末尾分配额外的空间，则可能会用到此属性。

从不同位置加载

您无法指定希望 DLLImport 在运行时从何处查找文件，但是可以利用一个技巧来达到这一目的。

DllImport 调用 LoadLibrary() 来完成它的工作。如果进程中已经加载了特定的 DLL，那么即使指定的加载路径不同，LoadLibrary() 也会成功。

这意味着如果直接调用 LoadLibrary()，您就可以从任何位置加载 DLL，然后 DllImport LoadLibrary() 将使用该 DLL。

由于这种行为，我们可以提前调用 LoadLibrary()，从而将您的调用指向其他 DLL。如果您在编写库，可以通过调用 GetModuleHandle() 来防止出现这种情况，以确保在首次调用 P/Invoke 之前没有加载该库。

P/Invoke 疑难解答

如果您的 P/Invoke 调用失败，通常是因为某些类型的定义不正确。以下是几个常见问题：

1.long != long。在 C++ 中，long 是 4 字节的整数，但在 C# 中，它是 8 字节的整数。

2.字符串类型设置不正确。

　　我们将在下边深入探讨在C#中使用Win32和其他库非.net托管函数的方法。 

C# 用户常提出两个问题：“为什么要另外 编写代码来使用windows内置功能？在框架中为什么没有相应的内容为我完成这一任务？”当框架小组构建他们的 .NET 部分时，他们评估了为使  .NET 程序员可以使用 Win32 而需要完成的工作，结果发现 Win32 API 集非常庞大。他们没有足够的资源为所有  Win32 API 编写托管接口、加以测试并编写文档，因此只能优先处理最重要的部分。许多常用操作都有托管接口，但是还有许多完整的 Win32  部分没有托管接口。 

平台调用 (P/Invoke) 是完成这一任务的最常用方法。要使用 P/Invoke，您可以编写一个 描述如何调用函数的原型，然后运行时将使用此信息进行调用。另一种方法是使用 Managed Extensions to C++ 来包装函数，这部分 内容将在以后的专栏中介绍。 

要理解如何完成这一任务，最好的办法是通过示例。在某些示例中，我只给出了部分代码；完整的代码可以通过下载获得。 

简单示例

在第一个示例中，我们将调用 Beep() API 来发出声音。首先，我需要为 Beep() 编写适当的定义。查看 MSDN 中的定义，我发现它具有以下原型： 

 

要用 C# 来编写这一原型，需要将 Win32 类型转换成相应的 C# 类型。由于 DWORD 是 4 字节的整数，因此我们可以使用 int  或 uint 作为 C# 对应类型。由于 int 是 CLS 兼容类型（可以用于所有 .NET 语言），以此比 uint 更常用，并且在多数情况 下，它们之间的区别并不重要。bool 类型与 BOOL 对应。现在我们可以用 C# 编写以下原型： 


这是相当标准的定义，只不过我们使用了 extern 来指明该函数的实际代码在别处。此原型将告诉运行时如何调用函数；现在我们需要告诉它在何处找到该函数。 

我们需要回顾一下 MSDN 中的代码。在参考信息中，我们发现 Beep() 是在 kernel32.lib 中定义的。这意味着运行时代码包含在 kernel32.dll 中。我们在原型中添加 DllImport 属性将这一信息告诉运行时： 

 

这就是我们要做的全部工作。下面是一个完整的示例，它生成的随机声音在二十世纪六十年代的科幻电影中很常见。 

  

它的声响足以刺激任何听者！由于 DllImport 允许您调用 Win32 中的任何代码，因此就有可能调用恶意代码。所以您必须是完全受信任的用户，运行时才能进行 P/Invoke 调用。 

枚举和常量

Beep() 可用于发出任意声音，但有时我们希望发出特定类型的声音，因此我们改用 MessageBeep()。MSDN 给出了以下原型： 

  

这看起来很简单，但是从注释中可以发现两个有趣的事实。 

首先，uType 参数实际上接受一组预先定义的常量。 

其次，可能的参数值包括 -1，这意味着尽管它被定义为 uint 类型，但 int 会更加适合。 

对于 uType 参数，使用 enum 类型是合乎情理的。MSDN 列出了已命名的常量，但没有就具体值给出任何提示。由于这一点，我们需要查看实际的 API。 

如果您安装了 Visual Studio? 和 C++，则 Platform SDK 位于 "Program Files"Microsoft Visual Studio .NET"Vc7"PlatformSDK"Include 下。 

为查找这些常量，我在该目录中执行了一个 findstr。 

findstr "MB_ICONHAND" *.h 

它确定了常量位于 winuser.h 中，然后我使用这些常量来创建我的 enum 和原型： 

  

现在我可以用下面的语句来调用它： MessageBeep(BeepType.IconQuestion);

　　处理结构 

有时我需要确定我笔记本的电池状况。Win32 为此提供了电源管理函数。 

搜索 MSDN 可以找到 GetSystemPowerStatus() 函数。 

  

此函数包含指向某个结构的指针，我们尚未对此进行过处理。要处理结构，我们需要用 C# 定义结构。我们从非托管的定义开始：

然后，通过用 C# 类型代替 C 类型来得到 C# 版本。

　　这样，就可以方便地编写出 C# 原型：

　　在此原型中，我们用“ref”指明将传递结构指针而不是结构值。这是处理通过指针传递的结构的一般方法。 

此函数运行良好，但是最好将 ACLineStatus 和 batteryFlag 字段定义为 enum：

请注意，由于结构的字段是一些字节，因此我们使用 byte 作为该 enum 的基本类型。 

字符串

虽然只有一种 .NET 字符串类型，但这种字符串类型在非托管应用中却有几项独特之处。可以使用具有内嵌字符数组的字符指针和结构，其中每个数组都需要正确的封送处理。 

在 Win32 中还有两种不同的字符串表示： 

ANSI 
Unicode 

最初的 Windows 使用单字节字符，这样可以节省存储空间，但在处理很多语言时都需要复杂的多字节编码。Windows NT? 出现后，它使用 双字节的 Unicode 编码。为解决这一差别，Win32 API 采用了非常聪明的做法。它定义了 TCHAR 类型，该类型在 Win9x 平台 上是单字节字符，在 WinNT 平台上是双字节 Unicode 字符。对于每个接受字符串或结构（其中包含字符数据）的函数，Win32 API 均 定义了该结构的两种版本，用 A 后缀指明 Ansi 编码，用 W 指明 wide 编码（即 Unicode）。如果您将 C++ 程序编译为单字 节，会获得 A 变体，如果编译为 Unicode，则获得 W 变体。Win9x 平台包含 Ansi 版本，而 WinNT 平台则包含 W 版本。

由于 P/Invoke 的设计者不想让您为所在的平台操心，因此他们提供了内置的支持来自动使用 A 或 W 版本。如果您调用的函数不存在，互操作层将为您查找并使用 A 或 W 版本。

通过示例能够很好地说明字符串支持的一些精妙之处。

　　学习WCF已有近两年的时间，其间又翻译了Juval的大作《Programming WCF Services》，我仍然觉得WCF还有更多的内容值得探索与挖掘。学得越多，反而越发觉得自己所知太少，直到现在，我也认为自己不过是初窥WCF的门径而已。

“学以致用”，如果仅仅是希望能够在项目中合理地应用WCF，那么对于程序员而言，可以有两种选择，一种是“知其然而不知其所以然”，只要掌握了WCF 的基础知识，那么对于一般的应用就足够了。要做到这一点就很容易了，微软秉承了一贯的方式，将WCF这门技术优雅地呈现给开发者，封装了复杂的实现逻辑， 提供了易于调用的类库和相关的工具，使得开发者能够快速地完成WCF程序的开发。另外一种方式自然就是深度挖掘WCF的内部实现了，这是对WCF专家提出 的要求。如果我们要应用WCF实现SOA解决方案，就会遭遇许多WCF的高级应用，如何合理、有效地应用WCF，并根据项目实际情况对WCF进行扩展，就 成为了WCF专家必须解决的难题。

因此，如果要学习WCF，你必须找准自己学习的动机与目标，然后合理地安排自己的学习进度表，这才是正确的学习方式。本文试图对WCF的一些基础概念作一些试探性的阐述与分析，并以问答的方式组织，希望能够部分解答一些希望学习WCF，但犹自徘徊在门外的开发者。

1、WCF是什么？

从WCF所处的位置来看，它是包含在.NET 3.0（也包括.NET 3.5）之中的。我们注意比较.NET 3.0与.NET 2.0，其实唯一的区别就是.NET 3.0包含了WCF、WPF、WF（或者还有CardSpace）而已。因此，我们认为WCF是.NET框架的一部分，似乎并不为过。尤为关键的是， WCF并不能脱离.NET框架而单独存在（但非WCF客户端可以调用WCF服务），因此，虽然WCF是微软用以应对SOA解决方案的开发需求而专门推出 的，但它并不是例如Spring、Struts那样的框架，也不是像EJB那样的容器或者服务器。微软真正符合SOA企业应用服务器角色的，我想应该是 Biztalk Server。

严格的说，WCF就是专门用于服务定制、发布与运行以及消息传递和处理的一组专门类的集合，也就是所 谓的“类库”。这些类通过一定方式被组织起来，共同协作，并为开发者提供了一个统一的编程模式。WCF之所以特殊，是在于它所应对的场景与普通的.NET 类库不同，它主要用于处理进程间乃至于机器之间消息的传递与处理，同时它引入了SOA的设计思想，以服务的方式公布并运行，以方便客户端跨进程和机器对服 务进行调用。实际上，WCF就是微软对于分布式处理的编程技术的集大成者，它将DCOM、Remoting、Web Service、WSE、MSMQ集成在一起，从而降低了分布式系统开发者的学习曲线，并统一了开发标准。

WCF与其它类库还有不同 的地方，则在于WCF充分地体现了运行时环境的概念。对于早期使用WCF的开发人员而言，就可能知道如果在.NET 2.0下要开发WCF，还需要专门下载一个Runtime Component 3.0版，其中就包含了WCF、WF等内容。在.NET中一贯存在所谓“宿主”的概念，整个.NET Framework（或者说是CLR）就可以认为是一个大的宿主，就像Java的虚拟机一样。由于WCF对服务有着专门的需求，对于服务端，需要发布和运 行服务；对于客户端，则需要调用服务；因而对于开发者，就需要编写定义、发布、运行、调用服务的相关代码。而服务就只能运行在特定的宿主上，这些宿主可以 是控制台应用程序进程、Windows或Web应用程序进程，也可以是Windows服务进程，或者为最常用的IIS宿主。在宿主内部，则封装了通道堆 栈，其中又包含了对协议、编码、消息传输、代理的处理。而在通道层的顶部，还提供了一个高级运行时，以针对应用程序的开发人员。

因而，我们可以这样认为，WCF是.NET Framework 3.x的一部分，它包含了用于服务定制、发布与运行以及消息传递和处理的运行时环境以及相关类的集合，它提供了在Windows平台下开发和部署服务的SDK。大致组成如下图所示：

2、WCF是怎样运行的？

如果从宏观的角度来分析WCF的运行机制，它的实现并不复杂。WCF的体系架构是基于一种拦截机制来实现的，负责传递和拦截消息的组件为通道，在客户端 发出对服务端服务的调用时，首先会通过一个服务代理对象，将调用方提供的对象序列化到消息中，然后该消息则通过通道进行传递。通道不只是包括一个，而是多 个通道对消息进行处理，包括传输、消息编码、管理会话、传播事务等，但最底层的通道总是传输通道。这些通道的构成形成了一个通道堆栈。由于对象已经被序列 化，因而此时通道传递的消息可以跨进程或机器进行传递，利用传输通道传递到服务端。服务端的构成与客户端基本相似，仍然是通过通道栈中最底层的传输通道接 收消息，然后解析消息编码，并一层层地往上传输。在服务端的通道栈之上，则是一个分发器（Dispatcher，或者说是调度器），它会首先对消息进行检 查，然后选择一个客户端要调用的操作。在这个过程中，消息会被反序列化。

下图说明了WCF的整个运行过程：

由于WCF通过通道的方式传递消息，整个通道同时担当了侦听器和拦截器的功能，它可以根据服务的定义，在方法执行的前或后执行不同的操作，例如事务、会 话管理、安全等。这些操作在WCF中，大多数都可以以Attribute的方式应用到服务契约上，这样的实现方式，就类似于采用了AOP（面向服务编程） 的方法为服务提供了大量的基础功能，有助于简化服务开发者的工作。

3、为什么我们要选用WCF？
在 Windows平台下，尤其是在.NET平台下开发面向服务的应用程序，或者开发分布式系统，最佳选择就是WCF。为什么呢？原因就在于WCF涵盖了之前 微软推出的所有用于分布式开发的技术，包括Remoting、Web Services、WSE、MSMQ等，并以一种统一的编程模式来实现。

WCF既支持具有互操作性的Web服务，也能够实现.NET客户端与.NET服务端的通信，提供了分布式事务的支持，同时在安全性上，它完全遵循了WS -*的标准，此外，它还支持队列服务，可以非常方便地利用消息队列完成异步操作与脱机调用。而这些功能，以前的技术都只是部分的实现。如下表所示：

特性	Web Service	.NET Remoting	Enterprise Services	WSE	MSMQ	WCF
具有互操作性的Web服务	支持					支持
.NET到.NET的通信		支持				支持
分布式事务			支持			支持
支持WS标准				支持		支持
消息队列					支持	支持

WCF同时也使得面向服务编程更加简单而统一了。如果采用旧有的技术，由于各种技术的编程模型完全不一致，使得程序的迁移非常的困难。例如，最初采用. NET Remoting技术开发的分布式系统，由于业务需求的变化，要求发布具有互操作性的Web服务，就需要重新定义服务。并且，客户端的调用方式也发生了变 化，需要添加Web引用，通过UDDI去发现服务。

采用WCF则不然。WCF引入了用通道，它封装了消息的通信细节，例如编码、事务 处理、安全等，然后又通过引入绑定的概念，封装了通道的组成顺序与处理细节。最后，引入了独有的Endpoint元素，集成了地址、绑定和契约之间的“三 位一体”，以最简单的方式定义和发布服务。

4、WCF基础的技术要素有哪些？

WCF的大部分功能都放在一个单独的程序集System.ServiceModel.dll中。WCF的几个最重要的技术元素包括：绑定、契约、端点。

如前所述，绑定封装了通道的组成顺序与处理细节，它直接决定了WCF的通信方式，消息的编码方式，通道的协议，消息传递的可靠性以及安全等内容。通过使 用绑定，我们就无需了解消息在WCF通道中的实现细节，从而简化程序员的开发。正是因为此，WCF为开发人员提供了多个内置绑定，基本上涵盖了WCF应用 的大部分场景。以下是Aaron Skonnard在《WCF深度绑定》一文中列举的内置绑定：

绑定类名称	传输	消息编码	消息版本	安全模式	可靠消息传送	事务流（默认情况下禁用）
BasicHttpBinding	HTTP	文本	SOAP 1.1	无	不支持	不支持
WSHttpBinding	HTTP	文本	SOAP 1.2 WS-Addressing 1.0	消息	禁用	WS-AtomicTransactions