为何Windows下的动态库总伴随一个静态库？

今天同学来问了一个问题：Visual Studio中生成的动态库总是伴随着一个静态库文件，我把这两个文件同样进行重命名之后还能不能使用？

我对VS下的动态库的生成并不是很熟悉，表示无法回答这个问题。但这个问题本身却也让我产生了疑问：动态库真的需要总是伴随着一个静态库？根据我在Linux下的经验，这两种形式的代码库是没有什么依赖关系的。 那在Windows下到底是怎么回事？带着这些疑问，我去搜索了一下。下面将得到的结论和一些相关知识进行总结。

静态链接库（.lib文件）其实是代码的简单集合，在Linux下扩展名为.a，表示archive（归档）之意。它只是将编译后的目标代码（.o文件）进行简单的归档，没什么特殊之处。我曾试过将Windows下的foo.lib文件直接命名为foo.a，直接在Linux下使用 （当然，前提是他们含有的目标代码必须一样，即编译时目标平台是一致的）。这些库在链接时被链接进可执行文件，如同.o文件被链接一样。静态库的作用无非是将多个.o集成为一个，便于管理和分享而已。

动态链接库（.dll文件）则相对复杂一些。动态库中的代码是在运行时根据需要加载的。由于这里面的代码在加载进内存后可以被多个程序共享，因此又称为共享库，在Linux下的扩展名为.so，表示shared objects（共享的目标代码）之意。

Windows下用VS创建DLL项目生成.dll文件时，一般会伴随生成一个.lib文件；使用这个.dll文件时，需要将伴随的.lib加进链接选项。事实上，这里的.lib文件中只包含简单的导出定义，实际的代码还是在.dll文件中。这里的.lib文件并非是上面提到的 静态库，而是动态链接库的导入库(Import Libary)。虽然共用扩展名，但它们的内容是完全不一样的。导入库只在链接的时候需要，程序运行的时候只需要.dll文件即可。此外，DLL项目中必须至少导出一个函数、变量或者类才会有.lib生成， 没有导出的话就不生成.lib文件。由于一般情况下DLL项目都是为了导出符号给别的项目用，所以才给人一种动态库总伴随着一个“静态库”文件的假象。

回到同学的问题。伴随的那个.lib文件里有相应的.dll文件的名字和一个指明.dll文件中函数入口的顺序表。如果把.dll文件的名称改了，.lib文件中相应的名字还是原来的文件名，应该就会找不到相应的.dll文件了。 但其实.dll文件在没有.lib文件的情况下也是可以使用的：通过WIN32 API函数LoadLibrary、GetProcAddress等函数来调用.dll中的函数即可。但这样比起有.lib文件时调用.dll中的函数稍微麻烦些。另外，Windows下也可以由.dll文件得到相应的.lib文件。 参见http://www.oschina.net/question/234345_48496。

那为什么在Linux下用GCC生成和使用.so文件时不需要类似.lib导入库这样的东西呢？直接原因是Windows下的链接器只能处理.lib这样的非可执行文件，不能处理.dll这样的可执行文件，所以用一个导入库（.lib）来辅助链接； 而在Linux下，.so文件是elf格式的，这种格式既可执行又能链接，所以GCC就没必要使用额外的文件来辅助链接共享库了。网上有人对Windows下导入库的概念给出了更深层一点的解释： DLL中导出的符号名未必是应用程序使用它时导入的符号名；为了方便得到对语言中立的组件，微软特意采用了现在的方案：在DLL里导出一套符号，然后通过DEF文件或”Import Library”来使用另一套符号进行导入，这样就相当于多了一层转换，可兼顾同语言和跨语言的应用。 这也是有道理的。