由MessageBox透视Win32 API的调用

下面我们来看看Windows平台下应用程序是怎么调用Windows提供的底层API服务运行的。

我们编写Win32SDK程序时，需要弹出对话框以作出友好的选择，MessageBox这个API函数就可以实现该功能。在开头要添加<windows.h>，因为其包含了众多的API函数声明头文件。为了探究这个小小的MessageBox是怎么弹出来的，我们右击MessageBox，选择“Go to definition of MessageBox(转到定义) ”将打开<winuser.h>中MessageBox定义处。MessageBox(A/W)的函数原型声明如下：

// WINUSER.H

WINUSERAPI

int

WINAPI

MessageBoxA(

HWND hWnd ,

LPCSTR lpText,

LPCSTR lpCaption,

UINT uType);

WINUSERAPI

int

WINAPI

MessageBoxW(

HWND hWnd ,

LPCWSTR lpText,

LPCWSTR lpCaption,

UINT uType);

#ifdef UNICODE

#define MessageBox MessageBoxW

#else

#define MessageBox MessageBoxA

#endif // !UNICODE

我们在使用Windows窗口操作系统时，经常会蹦出大大小小的窗口， MessageBox只是Windows作为提示的对话框窗口单元。那么，MessageBoxW这个API函数到底在哪里实现的呢？应用程序是如何调用系统接口函数的呢？

动态链接库（.dll）

初窥DLL

实际上Windows API函数是定义在一些DLL中的，DLL实现了代码封装，从这个角度来看DLL才是真正意义上的API函数包，它是非开源Windows操作系统提供给我们的底层接口。DLL的编制与具体的编程语言及编译器无关。

动态链接库dll文件（Linux中与之对应的是的.so）存放在C:/WINDOWS/system目录和C:/WINDOWS/system32目录下，它在被应用程序调用时才同程序相链接。

其中Windows系统最重要的DLL是User32.dll、Gdi32.dll和Kernel32.dll这三个库文件。这三个库文件中的API函数大都在头文件<windows.h>中进行了声明。从功能上进行分类，User32.dll（Windows XP USER API Client DLL）定义了窗口管理函数，包括窗口的创建、显示、设置和移动等；Gdi32.dll（GDI Client DLL）定义了图形设备函数（GDI），实现与设备无关的绘图功能；Kernel32.dll（Windows NT BASE API Client DLL）定义了系统服务函数，包括诸如内存调度、进程管理等与操作系统有关的底层功能。我们可以通过三种方式来查看DLL文件中的导出函数信息：（1）使用Windows系统的dumpbin命令（在命令行中：C:/WINDOWS/system32>dumpbin ntdll.dll /exports）；（2）使用VC自带的Depends工具（Microsoft Visual Studio 6.0 ToolsàDepends或Visual Studio 2005命令行提示àdepends）；（3）Dll函数查看器（ViewDll或ExeScope）。以下使用VC自带的Depends工具查看user32.dll中MessageBox函数系列。

DLL与API

正如Java的跨平台（Write Once, Run Everywhere）需要JVM的支持一样，C/C++成为跨平台的编程语言，依赖各个平台（包括操作系统和编译器）对C/C++标准函数库的具体平台实现。

VS编译器自带的标准C函数库<stdio.h>，<stdlib.h>，<string.h>，<math.h>中声明的函数可以到C:/Program Files/Microsoft Visual Studio/VC98/CRT/SRC(或C:/Program Files/Microsoft Visual Studio 8/VC/crt/src)中查看相关实现源代码。strcat.c文件提供了strcat和strcpy函数的源码 ,在Windows系统中，C:/WINDOWS/system32/ntdll.dll提供了strcat和strcpy这两个CRT API的底层实现。用户对C函数的调用最终通过调用底层API来完成真正的功能。例如C标准库函数create用于创建文件，但它是靠调用CreateFile（kernel32.dll）函数来完成创建文件功能的；beginthread(process.h,thread.c)需要调用 CreateThread（kernel32.dll）函数来完成线程的创建。

DLL的移植升级

Windows将遵循下面的搜索顺序来定位 DLL： 包含EXE文件的目录>进程的当前工作目录>Windows系统目录>Windows目录>列在 Path 环境变量中的一系列目录。

如果你在本机编写一个Windows应用程序，移植到其他机子上(当然也是Windows操作系统)，有可能因为缺少相关DLL文件而无法执行。因为DLL是动态链接，就是随用随加载，这就是为什么我们玩3D游戏时经常弹出缺少d3dx9***.dll的错误提示。如果启动的程序调用了一个过期的DLL文件或不匹配的DLL文件，则会出现“未定义的动态链接调用”消息。

动态链接库除了实现代码的共享外，其模块封装特性使得应用程序在调用一个DLL的不同版本时，只要导出的函数名相同就不必进行重新编译链接。这样，软件产品在更新或升级时，客户程序不必进行改动。在开发软件产品时，对于通用功能的函数，一般以DLL的形式来实现。Windows设备驱动程序就是体现上述特点的动态链接库。

DLL的调用

动态链接库的调用方式又分为隐式调用（也称静态调用，需要.lib文件）和显式调用（也称动态调用，LoadLibraryàGetProcAddressàFreeLibrary）。

那么，在我们编写的程序中，如何调用DLL中的API呢？既然用户对C函数的调用最终是通过调用底层API来完成真正的功能，那么，我们在编写第一个Hello World程序时就已经不知不觉地调用了DLL。实际上<stdio.h>中定义的printf函数由msvcrt.dll函数导出，而*printf系列函数在ntdll.dll中有具体底层实现。

DLL文件包括了具体实现的代码编译后的结果（二进制的机器码），而头文件中的代码主要是DLL库文件导出函数的原型声明。<winuser.h>即主要对user32.dll中导出的函数做声明索引，所以若要使用MessageBox(A/W)，需#include <winuser.h>（已被<windows.h>包含）。正如调用printf函数需要#include <stdio.h>。

在调用printf函数或MessageBox函数时，我们仅仅包含了声明头文件，没有显式LoadLibraryàGetProcAddress，那我们是如何是隐式调用（定位）DLL中的API的呢？实际上我们在利用VC向导生成一个Win32 Console Application时，向导已经为项目设置了link项（Project Settings àLinkàInputàObject/library modules），其中默认链接kernel32.lib、user32.lib、gdi32.lib等。

静态链接库（.lib）

目标代码集静态链接库

在早期库的组织形式相对简单，里面的目标代码只能够进行静态链接，所以我们称为“静态库”，静态库的结构比较简单，其实就是把原来的目标代码（*.obj)集合在一起，链接程序LINKER根据每一份目标代码的符号表查找相应的符号（函数和变量的名字），找到的话就把该函数里面需要定位的进行定位，然后将整块函数代码放进可执行文件里，若是找不到需要的函数就报错退出。标准Turbo C2.0中的C库函数，例如scanf、printf、memcpy、strcpy等，就是使用的静态库技术。

以下是C程序的编译链接过程：(1)执行cl /c main.c;cl /c lib1.c;cl /c lib2.c生成了main.obj lib1.obj lib2.obj三个文件；(2)执行link /lib lib1.obj;link /lib lib2.obj生成了2个文件lib1.lib lib2.lib；(3)执行link main.obj lib1.lib lib2.lib生成main.exe。

静态链接lib库（Linux中与之对应的是的.a）的两个特点：

（1）链接后产生的可执行文件包含了所有需要调用的函数的代码，因此占用磁盘空间较大。

（2）如果有多个（调用相同库函数的）进程在内存中同时运行，内存中就存有多份相同的库函数代码，因此占用内存空间较多。

DLL隐式调用静态链接库

使用DLL隐式链接时，可执行程序链接到一个包含DLL导出函数信息的输入库文件(.LIB文件)。操作系统在加载使用可执行程序时加载DLL。可执行程序直接通过函数名像调用其他源文件中的函数一样调用DLL中的导出函数。

我们可以用记事本打开C:/Program Files/Microsoft Visual Studio/VC98/Lib中的USER32.LIB文件，其中有

__imp__MessageBoxA@16_MessageBoxW@16 // 这里16为参数的字节数

? _MessageBoxW@16 USER32.dll USER32.dll/ 889206797

静态链接库lib文件中存放的是接口函数的入口地址，dll中存放的是函数实体。当我们隐式调用dll时，需要在Link选项指明其对应的lib库。lib告诉编译器你的dll都导出了什么函数，以及这些函数的相对地址，运行的时候就根据这些信息就可以找到dll中相应的API。

除了在“Project SettingsàLinkàInputàobject/library modules”中填写静态链接库（*.lib）外，我们还可以通过#pragma comment宏显示输入*.lib库文件，例如在网络编程中需要添加WS2_32.LIB库，则可以在文件的开头包含头文件后#pragma comment(lib,"WS2_32.LIB")引入静态链接库文件。

由于我们经常要调用一些第三方厂商或其他编译器编写的动态链接库，但是一般都不提供源文件或.lib文件。我们若知道相应API的函数原型，通过LoadLibraryàGetProcAddress以实现正确的调用。如果隐式调用，则需要lib文件，可使用DLL2LIB工具生成DLL对应的LIB文件。

在编写MFC项目时，我们打开Project SettingsàGeneral的Microsoft Foundation Classes里面有两种链接方式：Use MFC in a Static Library ，Use MFC in a Shared Library。对应在Visual Studio 2005中“项目属性à配置属性à常规àMFC的使用”中设置链接方式。

如果选择Use MFC in a Shared Library的话，你编译后的程序中不包含MFC库，所以文件会比较小，但是如果你的程序直接移到一个没有安装过MFC的机器上时，可能会导致找不到MFC的DLL，故发布时要带MFC得DLL文件。如果选择Use MFC in a Static Library，那么编译后的程序就直接包含了MFC的静态链接库（目标代码集，相当于基于源码级集成），文件可能会大一些，但是可以直接移到其他机器上运行，即发布时不用带MFC的DLL文件。

参考：

《动态链接库DLL的创建和使用》

《深入探究VC-编译器CL.EXE》

《隐式链接无.LIB动态链接库》