导入库如何工作？细节？

4 回答

• 2

  链接到DLL文件可以在编译链接时隐式发生，也可以在运行时显式发生 . 无论哪种方式，DLL最终都会加载到进程内存空间中，并且其所有导出的入口点都可供应用程序使用 .

  如果在运行时显式使用，则使用 LoadLibrary() 和 GetProcAddress() 手动加载DLL并获取指向需要调用的函数的指针 .

  如果在构建程序时隐式链接，则程序使用的每个DLL导出的存根将从导入库链接到程序，并且这些存根在进程启动时加载EXE和DLL时会更新 . （是的，我在这里简化了一点......）

  这些存根需要来自某个地方，而在Microsoft工具链中，它们来自一种称为导入库的特殊形式的.LIB文件 . 所需的.LIB通常与DLL同时构建，并包含从DLL导出的每个函数的存根 .

  令人困惑的是，同一个库的静态版本也将作为.LIB文件提供 . 除了作为DLL的导入库的LIB通常比匹配的静态LIB更小（通常小得多）之外，没有简单的方法可以区分它们 .

  如果您使用GCC工具链，顺便说一句，您实际上并不需要导入库来匹配您的DLL . 移植到Windows的Gnu链接器版本直接理解DLL，并且可以动态地合成大多数任何所需的存根 .

  更新

  如果您能够't resist knowing where all the nuts and bolts really are and what is really going on, there is always something at MSDN to help. Matt Pietrek'文章An In-Depth Look into the Win32 Portable Executable File Format是对EXE文件格式及其加载和运行方式的完整概述 . 它甚至已经更新，以涵盖.NET和更多，因为它最初出现在MSDN杂志ca. 2002年 .

  此外，知道如何准确了解程序使用的DLL是有帮助的 . 其工具是Dependency Walker，又名depends.exe . 它的一个版本包含在Visual Studio中，但最新版本可从其作者http://www.dependencywalker.com/获得 . 它可以识别在链接时指定的所有DLL（早期加载和延迟加载），它还可以运行程序并监视它在运行时加载的任何其他DLL .

  更新2

  我已经重新编写了一些早期的文本，以便在重新阅读时澄清它，并使用术语隐式和显式链接来与MSDN保持一致 .

  因此，我们有三种方法可供程序使用库函数 . 显而易见的后续问题是：“如何选择哪种方式？”

  静态链接是程序本身的大部分链接 . 列出了所有目标文件，并由链接器一起收集到EXE文件中 . 在此过程中，链接器负责处理一些小事，例如修复对全局符号的引用，以便您的模块可以打电话给对方的功能 . 库也可以静态链接 . 组成库的目标文件由.LIB文件中的库管理器收集在一起，链接器搜索包含所需符号的模块 . 静态链接的一个影响是只有程序使用的库中的那些模块才链接到它;其他模块被忽略 . 例如，传统的C数学库包括许多三角函数 . 但是如果你链接它并使用 cos() ，你不会得到 sin() 或 tan() 代码的副本，除非你也调用了这些函数 . 对于具有丰富功能的大型库，选择性地包含模块非常重要 . 在诸如嵌入式系统的许多平台上，与可用于在设备中存储可执行文件的空间相比，可用于库中的代码的总大小可能很大 . 如果没有选择性包含，那么管理这些平台的构建程序的细节将更加困难 .

  但是，在每个运行的程序中都拥有相同库的副本会给通常运行大量进程的系统带来负担 . 使用正确类型的虚拟内存系统，具有相同内容的内存页只需要在系统中存在一次，但可以被许多进程使用 . 这样可以增加包含代码的页面可能与尽可能多的其他运行进程中的某个页面相同的机会 . 但是，如果程序静态链接到运行时库，那么每个程序都有不同的功能组合，每个功能都在不同位置的进程内存映射中布局，并且没有很多可共享的代码页，除非它本身就是一个程序 . 在多个过程中运行 . 因此，DLL的想法获得了另一个主要优势 .

  库的DLL包含其所有功能，可供任何客户端程序使用 . 如果许多程序加载该DLL，它们都可以共享其代码页 . 每个人都赢了 . （好吧，直到你用新版本更新DLL，但这不是这个故事的一部分 . 谷歌DLL地狱的故事的那一面 . ）

  因此，在规划新项目时做出的第一个重大选择是在动态和静态链接之间 . 使用静态链接，您可以安装较少的文件，并且您可以免受第三方更新您使用的DLL的影响 . 但是，您的程序更大，并且它不是Windows生态系统的良好公民 . 使用动态链接，您需要安装更多文件，第三方更新您使用的DLL时可能会遇到问题，但您通常对系统上的其他进程更友好 .

  DLL的一大优点是可以加载和使用它而无需重新编译甚至重新链接主程序 . 这可以允许第三方库提供程序（例如Microsoft和C运行时）修复其库中的错误并进行分发 . 一旦最终用户安装了更新的DLL，他们就会立即从使用该DLL的所有程序中获得该错误修复的好处 . （除非它破坏了东西 . 请参阅DLL Hell . ）

  另一个优点来自隐式加载和显式加载之间的区别 . 如果你需要额外的显式加载工作，那么在编写和发布程序时，DLL可能甚至不存在 . 例如，这允许可以发现和加载插件的扩展机制 .

  回复于 2024-04-26T22:24:26+08:00
• 3

  当通过lib文件构建一堆dll 's that need additional information at link time which is supplied by the import library .LIB files. In the example below to not get linker errors I need to reference to dll'的A，B，C和D时，这些.LIB导入库文件在以下项目属性 Linker->Input->Additional Dependencies 中使用 . （请注意，链接器要查找这些文件，您可能需要在_1577117中包含它们的部署路径，否则您将收到有关无法找到任何提供的lib文件的构建错误 . ）

  

  如果您的解决方案正在构建所有动态库，那么您可以通过依赖于 Common Properties->Framework and References 对话框下公开的引用标志来避免此显式依赖项规范 . 这些标志似乎使用* .lib文件代表您自动执行链接 .
  

  然而，这就是它所说的公共属性，它不是配置或平台特定的 . 如果您需要像我们的应用程序一样支持混合构建场景，我们有一个构建配置来呈现静态构建和一个特殊配置，该构造构建了部署为动态库的程序集子集的约束构建 . 在各种情况下，我使用 Use Library Dependency Inputs 和 Link Library Dependencies 标志设置为true来获取构建并稍后实现简化操作但是当我将代码引入静态构建时，我引入了大量的链接器警告，并且构建对于静态构建来说非常慢 . 我最后介绍了一堆这样的警告......

  warning LNK4006: "bool __cdecl XXX::YYY() already defined in CoreLibrary.lib(JSource.obj); second definition ignored  D.lib(JSource.obj)
  

  最后，我使用 Additional Dependencies 的手动规范来满足动态构建的链接器，同时通过不使用减慢它们的公共属性来保持静态构建器的快乐 . 当我部署动态子集构建时，我只部署dll文件，因为这些lib文件仅在链接时使用，而不是在运行时使用 .

  回复于 2024-04-26T22:24:26+08:00
• 1

  有三种库：静态库，共享库和动态加载库 .

  静态库在链接阶段与代码链接，因此它们实际上位于可执行文件中，与共享库不同，共享库只有在共享库文件中查找的存根（符号），该文件在运行时加载 . 主函数被调用 .

  动态加载的文件很像共享库，除非在您编写的代码需要时加载它们 .

  回复于 2024-04-26T22:24:26+08:00
• 77

  以下是一些相关的MSDN主题来回答我的问题：

  Linking an Executable to a DLL

  Linking Implicitly

  Determining Which Linking Method to Use

  Building an Import Library and Export File

  回复于 2024-04-26T22:24:26+08:00