使用 .DLL .LIB 的问题（针对VC）

1。调用DLL的概述。

应用程序导入函数与DLL文件中的导出函数进行链接有两种方式：隐式链接和显式链接。所谓的隐式链接是指在应用程序中不需指明DLL文件的实际存储路径，程序员不需关心DLL文件的实际装载。而显式链接与此相反。

采用隐式链接方式，所有被应用程序调用的DLL文件都会在应用程序EXE文件加载时被加载在到内存中，程序员在建立一个DLL文件时，链接程序 (1.注意，链接程序即所谓的Linker,这个就是我们在调用DLL时应该在 Project | Settings | Link | Object/library modules: 中添加的.lib 路径，这个路径可以不在调用者的Project里面.) 会自动生成一个与之对应的LIB导入文件。该文件包含了每一个DLL导出函数的符号名和可选的 标识号，但是并不含有实际的代码。LIB文件作为DLL的替代文件被编译到应用程序项目中。当程序员通过静态链接方式编译生成应用程序时，应用程序中的调 用函数与LIB文件中导出符号相匹配，这些符号或标识号进入到生成的EXE文件中。LIB文件中也包含了对应的DLL文件名（但不是完全的路径名），链接 程序将其存储在EXE文件内部。当应用程序运行过程中需要加载DLL文件时，Windows根据这些信息发现并加载DLL，然后通过符号名或标识号实现对 DLL函数的动态链接。2.注意，采用隐式链接的时候，.Lib 文件必须同自己的头文件 *.h 结合使用，所以这就是我们在 Project | Settings | C/C++ | Settings | Preprocessor | Additional include directories field: 应该填入的.h 文件的路径，而且在程序中也应该引用 #include *.h。这样程序才能在Compile的时候找到所需要的 .lib 和 .h 文件。

采用显式链接方式，显式链接在运行时决定加载哪个DLL文件，程序员就不必再使用导入文件(不用在Project里面设置.lib的路径了)，而是直接调用Win32 的LoadLibary函数，并指定DLL的路径作为参数。LoadLibary返回HINSTANCE参数，应用程序在调用 GetProcAddress函数时使用这一参数。GetProcAddress函数将符号名或标识号转换为DLL内部的地址。

2。.Lib 文件和 .Dll 文件的对比

对比前文中所说的关于 .Lib 文件和 .Dll 文件，我们总结一下他们的不同点。
(1)可以说 .lib 文件是编译时需要的，.dll 文件是运行时需要的。
如果要完成源代码的编译，有lib就够了。
如果也使显式链接的程序运行起来，有dll就够了。
DLL是一个完整程序,意味着它已经被编译被链接，和一个.exe 文件的性质差不多。有导出表，与导入表。
LIB是一个函数库，或者说是一个lookup-table，当调用DLL的程序用到某个程序的时候，它就是指示去哪里找这个函数的表，它是被编译了，但没有被链接, 如果想看到其它相关的不同,用lib.exe就知道了。

(2)一般的动态库程序有lib文件和dll文件。lib文件是必须在编译期就连接到应用程序中的，而dll文件是运行期才会被调用的。如果有 dll文件，那么对应的lib文件一般是一些索引信息，具体的实现在dll文件中。如果只有lib文件，那么这个lib文件是静态编译出来的，索引和实现 都在其中。静态编译的lib文件有好处：给用户安装时就不需要再挂动态库了。但也有缺点，就是导致应用程序比较大，而且失去了动态库的灵活性，在版本升级 时，同时要发布新的应用程序才行。
(3)生成DLL文件时，有两个文件，一个是引入库（.LIB）文件，一个是DLL文件，.Lib文件包含被DLL导出的函数的名称和位 置，.DLL 包含实际的函数和数据，应用程序使用LIB文件链接到所需要使用的DLL文件，库中的函数和数据并不复制到可执行文件中，因此在应用程序的可执 行文件中，存放的不是被调用的函数代码，而是DLL中所要调用的函数的内存地址，这样当一个或多个应用程序运行是再把程序代码和被调用的函数代码链接起 来，从而节省了内存资源。从上面的说明可以看出，DLL和.LIB文件必须随应用程序一起发行，否则应用程序将会产生错误。

注：文中小的标号1，2 是在调用的时候需要注意的，可以查看我的另外一篇文章：http://hi.baidu.com/kxw102/blog/item/58b76aa5de7b45f09152ee3a.html