Windows 使用DEF文件而不是LIB文件链接到DLL？

我知道你可以：

将.DLL文件转换为包含其导出的.DEF文件 编辑：这不适用于许多约定 将.DEF文件转换为.LIB文件，您可以使用该文件链接到DLL

---

为什么大多数链接器不能链接到只提供.DEF文件而不是.LIB文件的DLL？

您不会将DLL转换为DEF文件。DEF只是指示哪些dll函数可以从外部访问、导出

从：

DLL文件的布局与.exe文件非常相似，只有一个 重要区别-DLL文件包含导出表。这个 exports表包含DLL导出的每个函数的名称 到其他可执行文件。这些函数是进入 动态链接库；其他用户只能访问导出表中的函数 可执行文件。DLL中的任何其他函数都是DLL的专用函数。 可以使用DUMPBIN工具查看DLL的导出表 使用/EXPORTS选项

可以使用两种方法从DLL导出函数：

创建模块定义.def文件，并在需要时使用.def文件 构建DLL。如果要导出函数，请使用此方法 按顺序而不是按名称从DLL中删除

在函数定义中使用关键字uu declspecdllexport

使用任一方法导出函数时，请确保使用 __stdcall调用约定

使用提供的链接了解有关从dll导出的详细信息

---

我想你被否决了，因为你的观点不是很清楚，至少对我来说不是。也检查一下。它解释了如何选择导出方法。

Mehrdad，这并不总是如何链接到DLL的问题，因为我个人从未使用.DEF文件链接过DLL。我所做的就是利用别人的DLL，非常辛苦地构建了一个头文件，或者更确切地说，是我可以使用的函数原型 C中的LoadLibrary，声明函数。。。VB中的Lib Foo.dll别名序号名称，以及 [DllImport]在C中

当然，这是很少做到的，因为如果您正在使用某个DLL，通常您有这样做的权限，并且作者提供了.lib以及二进制DLL文件的头文件

我从未使用过您所说的确切技术，通过将.DEF info转换为.LIB等。。。但是，我认为获取一个lib或DLL本身并从中导出.DEF是很容易的。现在，我实际上已经完成了，在一个项目中，DLL代码是用vbScript构建的，vbScript从主项目中获取代码，并用所有现有的、编译的和测试过的代码创建了一个API。之所以会出现这种复杂程度，是因为我不知道DLL中将包含哪些函数，因为主项目可能随时发生更改，因此静态.DEF文件永远不会工作。因此，我必须构建一次DLL，捕获dimpbin/exports，取消修饰函数，然后构建.DEF文件，并重新链接DLL

如果你发现自己处于这种情况，也许你需要重新思考你的原始设计，并从那里解决问题

---

至于.LIB文件，通常您只需要用于静态链接，但是当.H文件可用时，也会使用它们，这通常会使调试变得更好一些……

最终，这里的答案是“因为没有人非常想要它，而且它实际上没有任何帮助”

DEF文件是为DLL创建导入库的输入文件。然后，当DLL被另一个链接使用时，importlib本身就是一个输入。importlib在外观上看起来很特殊，但从内部看，它实际上只是一个带有对象的稍微特殊的lib

完全可以修改链接器以直接获取def文件或DLL

但是链接器的设计中心是它将对象作为输入并输出一个PE可执行文件。因此，将DEF或DLL作为输入超出了设计模式

除此之外，这是毫无意义的——允许链接器将DEF文件或DLL作为输入既不会启用任何重要的新场景，也不会阻止任何东西。将一个没有实际DLL的DEF文件转换成一个可用的importlib只需几分钟，只需为每个DEF条目创建一个伪空函数并链接它即可。因此，没有理由添加直接链接DEF文件的功能

---

Martyn

就MSVC而言，.lib文件始终是静态库。它们作为一个编译单元与所有编译的.c/.cpp文件链接在一起，因此库的所有代码都包含在最终的可执行文件中

然而，一些.lib文件，特别是大多数Windows系统文件，只包含存根，这些存根告诉操作系统在加载时加载所需的DLL，然后存根将函数调用路由到DLL。但是，那些 ubs静态链接到您的可执行文件中。然后，您的程序将使用DLL并获得其所有优点和缺点，但由于它所需的命名DLL函数位于.lib中，因此实际上位于可执行文件本身，因此您的代码不必知道它使用的是专门使用declspecdlimport的DLL

---

.def文件仅在创建.dll期间用作一种设置或配置文件，以指定该文件应导出的函数。它无法链接到，因为它并没有真正描述链接者理解的任何内容。

+1感谢您提供的信息；但是，您不将dll转换为DEF文件的假设并不总是正确的。我有时这样做，我也见过其他人这样做，有时是因为库文件不可用于DLL。您可能会争辩说，首先不应该使用DLL，但有时会发生这种情况。