问题描述
我知道这可能看起来很基本，以怪才。但我想让它晶莹剔透。
I know this may seem quite basic to geeks. But I want to make it crystal clear.
当我想用一个Win32 DLL时，通常只需要调用API，如调用LoadLibrary（）和GetProcAdderss（）。但最近，我与DirectX9的发展，我需要添加的 d3d9.lib 的 d3dx9.lib 的等文件。
When I want to use a Win32 DLL, usually I just call the APIs like LoadLibrary() and GetProcAdderss(). But recently, I am developing with DirectX9, and I need to add d3d9.lib, d3dx9.lib, etc files.
我听说足够lib是静态链接和DLL是动态链接。
I have heard enough that LIB is for static linking and DLL is for dynamic linking.
所以，我目前的理解是，LIB包含的方法的实现和链接时静态链接作为最终的EXE文件的一部分。尽管DLL是在运行时动态加载的，而不是最终的EXE文件的一部分。
So my current understanding is that LIB contains the implementation of the methods and is statically linked at link time as part of the final EXE file. While DLL is dynamic loaded at runtime and is not part of the final EXE file.
但有时候，有一些是LIB文件的与未来的DLL文件，因此：
But sometimes, there're some LIB files coming with the DLL files, so:
- 这些是什么LIB文件？
- 他们如何实现他们都是为了？
- 有没有可以让我检查这些LIB文件的内部任何工具？
检查后维基百科，我记得这些LIB文件被称为。
但我想知道它是如何工作与我的主要应用和动态加载的DLL。
After checking wikipedia, I remember that these LIB files are called import library.But I am wondering how it works with my main application and the DLLs to be dynamically loaded.
正如RBerteig表示，目前正处于与生俱来的的DLL的LIB文件存根一些code。所以调用顺序应该是这样的：
Just as RBerteig said, there're some stub code in the LIB files born with the DLLs. So the calling sequence should be like this:
我的主要应用程序 - >存根在LIB - >真正的目标DLL
My main application --> stub in the LIB --> real target DLL
那么，什么信息应该被包含在这些库？我能想到如下：
So what information should be contained in these LIBs? I could think of the following:
- 的lib文件应包含相应的DLL的完整路径;因此，DLL可以由运行时加载。
- 的相对地址（或文件偏移？）应该是在恩存根codeD;所以，正确的跳/方法调用可以作出。
每个DLL导出方法的入口点的
我说的对这个？有更多的东西？
Am I right on this? Is there something more?
BTW：有没有可以检查一个导入库中的任何工具？如果我能看到它，就会有没有更多的疑惑。
推荐答案
链接到一个DLL文件可能会出现的隐的编译在链接时，或明确的在运行时。无论哪种方式，该DLL最终装入进程的内存空间，和所有其导出的入口点可向应用
Linking to a DLL file can occur implicitly at link time, or explicitly at run time. Either way, the DLL ends up loaded into the processes memory space, and all of its exported entry points are available to the application.
如果在运行时明确地使用，可以使用调用LoadLibrary（）和 GetProcAddress的（）手动加载DLL并获得指针，你需要调用的函数。
If used explicitly at run time, you use LoadLibrary() and GetProcAddress() to manually load the DLL and get pointers to the functions you need to call.
如果联含蓄的程序编译，然后存根BYT程序获得在从导入库程序链接所使用的每个DLL导出，而那些存根得到更新的EXE和DLL加载时，进程启动。 （是的，我已经简化比多一点在这里...）
If linked implicitly when the program is built, then stubs for each DLL export used byt the program get linked in to the program from an import library, and those stubs get updated as the EXE and the DLL are loaded when the process launches. (Yes, I've simplified more than a little here...)
这些存根需要从什么地方来，并在微软的工具链，他们来自的.lib文件的一种特殊形式称为的导入库的。所需的.lib通常在同一时间作为DLL的构建，并包含从DLL导出每个函数的存根。
Those stubs need to come from somewhere, and in the Microsoft tool chain they come from a special form of .LIB file called an import library. The required .LIB is usually built at the same time as the DLL, and contains a stub for each function exported from the DLL.
令人困惑的是，相同的库的静态版本也将被运往作为.LIB文件。没有琐碎的方式来告诉他们分开，但LIBS是对DLL的导入库通常会更小（通常小得多），比匹配的静态库会。
Confusingly, a static version of the same library would also be shipped as a .LIB file. There is no trivial way to tell them apart, except that LIBs that are import libraries for DLLs will usually be smaller (often much smaller) than the matching static LIB would be.
如果您使用GCC工具链，顺便说一句，你实际上并不需要导入库，以配合您的DLL。移植到Windows GNU链接器的版本直接理解的DLL，并能合成动态最所有必需的存根。
If you use the GCC toolchain, incidentally, you don't actually need import libraries to match your DLLs. The version of the Gnu linker ported to Windows understands DLLs directly, and can synthesize most any required stubs on the fly.
更新：如果你只是无法抗拒知道，所有的螺母和螺栓真的是和什么是真正回事，总有一些东西在MSDN帮助。马特Pietrek着的文章 在深入查找到的Win32可移植可执行文件格式 是EXE文件的格式非常完整的概述，它如何被加载并运行。它甚至被更新，以涵盖.NET，更因为它最初出现在MSDN杂志约2002
Update: If you just can'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's article An In-Depth Look into the Win32 Portable Executable File Format is a very complete overview of the format of the EXE file and how it gets loaded and run. Its even been updated to cover .NET and more since it originally appeared in MSDN Magazine ca. 2002.
此外，它可以有助于了解如何学习的DLL由程序所使用的是什么。对于该工具的Dependency Walker，又名Depends.exe分析。它的一个版本包含在Visual Studio中，但最新版本可以从它的作者在 http://www.dependencywalker.com/。它可以识别所有的链接时（包括早期的负载和延迟负载）中指定的DLL文件，并且它也可以运行该程序并等待它在运行时加载任何额外的DLL。
Also, it can be helpful to know how to learn exactly what DLLs are used by a program. The tool for that is Dependency Walker, aka depends.exe. A version of it is included with Visual Studio, but the latest version is available from its author at http://www.dependencywalker.com/. It can identify all of the DLLs that were specified at link time (both early load and delay load) and it can also run the program and watch for any additional DLLs it loads at run time.
更新2
我已经改写了一些早期的文字阐明它审读，并用艺术的条件的隐的和的显式链接的与MSDN的一致性。
I've reworded some of the earlier text to clarify it on re-reading, and to use the terms of art implicit and explicit linking for consistency with MSDN.
所以，我们必须要通过一个程序使用的库函数可能会提供三种方式。最明显的跟进问题是，那么：怎么我选择哪种方式
So, we have three ways that library functions might be made available to be used by a program. The obvious follow up question is then: "How to I choose which way?"
静态链接是程序本身的体积是如何联系在一起的。您的所有目标文件中列出，并通过链接器的EXE文件得到收集在一起。一路上，连接器需要照顾未成年人的琐事像引用固定到全局符号，使你的模块可以相互调用的功能。图书馆也可以静态链接。该目标文件补库的是由其中连接器包含所需的符号模块搜索一个文件.LIB馆员一起收集。静态链接的一个效果是，只有从由链接到它的程序中使用的库的模块;其他模块将被忽略。例如，传统的C数学库包含许多三角函数。但是，如果您链接反对，使用 COS（），你不与的code的副本罪结束了（） 或棕褐色（），除非你也叫这些功能。对于具有丰富的功能集大型图书馆，模块的这种选择性包容是很重要的。在许多平台诸如嵌入式系统，$ C $的c可供使用的总大小中的库可以相比可用于存储在该设备的可执行程序的空间是大的。如果没有选择包容性，这将是更难管理建设方案的细节为这些平台。
Static linking is how the bulk of the program itself is linked. All of your object files are listed, and get collected together in to the EXE file by the linker. Along the way, the linker takes care of minor chores like fixing up references to global symbols so that your modules can call each other's functions. Libraries can also be statically linked. The object files that make up the library are collected together by a librarian in a .LIB file which the linker searches for modules containing symbols that are needed. One effect of static linking is that only those modules from the library that are used by the program are linked to it; other modules are ignored. For instance, the traditional C math library includes many trigonometry functions. But if you link against it and use cos(), you don't end up with a copy of the code for sin() or tan() unless you also called those functions. For large libraries with a rich set of features, this selective inclusion of modules is important. On many platforms such as embedded systems, the total size of code available for use in the library can be large compared to the space available to store an executable in the device. Without selective inclusion, it would be harder to manage the details of building programs for those platforms.
然而，在每一个程序运行具有的相同的库的副本创建一个正常运行大量进程的系统上的负担。用正确的一种虚拟存储系统的，在存储器的页具有相同内容只需要系统中存在一次，但可以通过许多方法来使用。这对于增加含有code中的网页可能是相同的一些页面在许多其它运行的进程尽可能的机会创建一个好处。但是，如果程序静态链接到运行时库，那么每个人都有的，每个奠定了功能不同组合在不同的地点处理内存映射，并没有很多的共享code页，除非它是一个程序，所有本身比过程更被运行。因此，一个DLL的想法获得了另一个重大，优势。
However, having a copy of the same library in every program running creates a burden on a system that normally runs lots of processes. With the right kind of virtual memory system, pages of memory that have identical content need only exist once in the system, but can be used by many processes. This creates a benefit for increasing the chances that the pages containing code are likely to be identical to some page in as many other running processes as possible. But, if programs statically link to the runtime library, then each has a different mix of functions each laid out in that processes memory map at different locations, and there aren't many sharable code pages unless it is a program that all by itself is run in more than process. So the idea of a DLL gained another, major, advantage.
一个一个库DLL包含它的所有功能，随时为任何客户端程序的使用。如果许多程序加载该DLL，它们都可以共享其code页面。人人都是赢家。 （好吧，直到你更新新版本一个DLL，但是这不是这个故事的一部分。谷歌DLL地狱的故事的那一面。）
A DLL for a library contains all of its functions, ready for use by any client program. If many programs load that DLL, they can all share its code pages. Everybody wins. (Well, until you update a DLL with new version, but that isn't part of this story. Google DLL Hell for that side of the tale.)
因此，第一个大的抉择，当规划一个新的项目是动态的，静态链接之间。与静态链接，你有较少的文件进行安装，并正在从第三方更新你使用一个DLL免疫。但是，你的程序是大，它不是Windows生态系统的那么好公民。有了动态链接，你有更多的文件来安装，你可能有一个第三方更新你使用一个DLL的问题，但你一般是友好给其他进程在系统上。
So the first big choice to make when planning a new project is between dynamic and static linkage. With static linkage, you have fewer files to install, and you are immune from third parties updating a DLL you use. However, your program is larger, and it isn't quite as good citizen of the Windows ecosystem. With dynamic linkage, you have more files to install, you might have issues with a third party updating a DLL you use, but you are generally being friendlier to other processes on the system.
一个DLL的一大优势是，它可以被加载并无需重新编译或重新链接，甚至主要的程序中使用。这可以允许第三方库提供商（认为微软和C运行时，例如），以修复自己的库中的缺陷和分发。一旦最终用户安装更新后的DLL，他们立即得到错误修复的好处在使用该DLL的所有程序。 （除非它打破的东西。见DLL地狱。）
A big advantage of a DLL is that it can be loaded and used without recompiling or even relinking the main program. This can allow a third party library provider (think Microsoft and the C runtime, for example) to fix a bug in their library and distribute it. Once an end user installs the updated DLL, they immediately get the benefit of that bug fix in all programs that use that DLL. (Unless it breaks things. See DLL Hell.)
其他的优势来自于隐性和显性负荷之间的区别。如果你去明确加载额外的努力，那么DLL甚至可能没有在程序编写和出版的时候存在。这允许，可以发现和加载插件，比如扩展机制。
The other advantage comes from the distinction between implicit and explicit loading. If you go to the extra effort of explicit loading, then the DLL might not even have existed when the program was written and published. This allows for extension mechanisms that can discover and load plugins, for instance.
这篇关于如何导入库工作？细节？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！