我在自己最近的编程中注意到一个趋势，正是这个趋势才引出本月的专栏主题。最近，我在基于 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 时，不要使应用程序逻辑直接属于任何外部方法或其中的构件。如果您遵循这个小规则，从长远看经常会省去许多的麻烦。

aspx?fig=true#fig1" target="_blank">图 1 中的代码显示了我所讨论的 MessageBeep 外部方法的最少附加代码。aspx?fig=true#fig1" target="_blank">图 1 中并没有任何显著的变化，而只是对无包装的外部方法进行一些普通的改进，这可以使工作更加轻松一些。从顶部开始，您会注意到一个名为 Sound 的完整类型，它专用于 MessageBeep。如果我需要使用 Windows API 函数 PlaySound 来添加对播放波形的支持，则可以重用 Sound 类型。然而，我不会因公开单个公共静态方法的类型而生气。毕竟这只是应用程序代码而已。还应该注意到，Sound 是密封的，并定义了一个空的私有构造函数。这些只是一些细节，目的是使用户不会错误地从 Sound 派生类或者创建它的实例。

aspx?fig=true#fig1" target="_blank">图 1 中的代码的下一个特征是，P/Invoke 出现位置的实际外部方法是 Sound 的私有方法。这个方法只是由公共 MessageBeep 方法间接公开，后者接受 BeepTypes 类型的参数。这个间接的额外层是一个很关键的细节，它提供了以下好处。首先，应该在类库中引入一个未来的 beep 托管方法，可以重复地通过公共 MessageBeep 方法来使用托管 API，而不必更改应用程序中的其余代码。

该包装方法的第二个好处是：当您进行 P/Invoke 调用时，您放弃了免受访问冲突和其他低级破坏的权利，这通常是由 CLR 提供的。缓冲方法可以保护您的应用程序的其余部分免受访问冲突及类似问题的影响（即使它不做任何事而只是传递参数）。该缓冲方法将由 P/Invoke 调用引入的任何潜在的错误本地化。

将私有外部方法隐藏在公共包装后面的第三同时也是最后的一个好处是，提供了向该方法添加一些最小的 CLR 样式的机会。例如，在aspx?fig=true#fig1" target="_blank">图 1 中，我将 Windows API 函数返回的 Boolean 失败转换成更像 CLR 的异常。我还定义了一个名为 BeepTypes 的枚举类型，它的成员对应于同该 Windows API 一起使用的定义值。由于 C# 不支持定义，因此可以使用托管枚举类型来避免幻数向整个应用程序代码扩散。

包装方法的最后一个好处对于简单的 Windows API 函数（如 MessageBeep）诚然是微不足道的。但是当您开始调用更复杂的非托管函数时，您会发现，手动将 Windows API 样式转换成对 CLR 更加友好的方法所带来的好处会越来越多。越是打算在整个应用程序中重用 interop 功能，越是应该认真地考虑包装的设计。同时我认为，在非面向对象的静态包装方法中使用对 CLR 友好的参数也并非不可以。

DLL Import 属性

现在是更深入地