为什么当我们获得实际的.dll实现时，我们还需要一个.lib存根文件？ [英] Why do we still need a .lib stub file when we've got the actual .dll implementation?

问题描述

我想知道为什么连接器不能通过查看具有实际实现代码的实际.dll文件中的信息来完成他们的工作？我的意思是为什么连接器仍然需要.lib文件来进行隐式链接？

i'm wondering why linkers can not do their job simply by consulting the information in the actual .dll files that got the actual implementation code ? i mean why linkers still need .lib files to do implicit linking ?

不是导出和相对地址表足够这样的链接？

are not the export and relative address tables enough for such linking ?

无论如何，只能使用.dll stub / proxy文件，只能使用.dll进行隐式链接？

is there anyway by which one can do implicit linking using only the .dll without the .lib stub/proxy files ?

我以为windows可执行的加载程序将代表程序（因此名称隐式链接）简单地执行LoadLibrary / LoadLibraryEx调用，这是显式链接的主要区别。如果这是真的，那么在没有.lib的情况下明确地做它应该表明它是可行的，没有它隐含的，对吧？或者我只是说没有意义？

i thought the windows executable loader would simply do LoadLibrary/LoadLibraryEx calls on behalf of the program (hence the name implicit linking) which is the main difference to explicit linking. if that is true then doing it explicitly without .lib should indicate that it is doable without it implicitly, right ? or i'm just saying non sense ?

任何帮助都赞赏，非常感谢：）

any help is appreciated, many thanks :)

geeko

推荐答案

我可以想到几个原因。

• 使用.lib文件意味着您可以构建不同于您的系统的DLL版本，只要您安装了正确的SDK。


• 编译器和连接器需要支持跨平台编译 - 您可能正在32位平台上构建64位目标，反之亦然，并且没有正确的体系结构DLL。


• 。 lib文件使您能够隐藏实现的某些部分 - 您可以具有不显示在.lib中但可通过GetProcAddress发现的私有导出。您也可以执行序数导出，在这种情况下，它们没有导出友好的名称，但在.lib中将有一个友好的名称。


• 本机DLL没有强名称，所以可能会收到错误的DLL版本。


• 最重要的是，这项技术是在20世纪80年代设计的。如果它是今天设计的，那么它可能会更接近你所描述的内容 - 例如.NET，你只需要引用目标程序集，并且拥有使用它所需的一切。

• Using .lib files mean you can build for a different version of a DLL than you have on your system, provided you just have the correct SDK installed.
• Compilers & linkers need to support cross-platform compilations - You might be building for a 64-bit target on a 32-bit platform and vice-versa and not have the correct architecture DLL present.
• .lib files enable you to "hide" certain parts of your implementation - you could have private exports that do not show up in the .lib but are discoverable via GetProcAddress. You can also do ordinal exports in which case they don't have a friendly name exported, but would have a friendly name in the .lib.
• Native DLL's do not have strong names, so it may be possible to pick up the wrong version of the DLL.
• And most importantly, this technology was designed in the 1980's. If it were designed today, it'd probably be closer to what you describe - for instance, .NET you just need to reference the target assembly and you have everything you need to use it.

我不知道有什么办法只用DLL来隐式连接 - 快速搜索显示了几个工具，但我没有使用任何一个。

I don't know of any way to do implicit linking solely with the DLL - A quick search revealed several tools, but I haven't used any of them.

在这种情况下，我将使用您需要使用的函数创建一个单独的源文件，并动态加载DLL并根据需要进行绑定。例如：

In this case, I would create a separate source file with the functions you need to use, and dynamically load the DLL and bind them as needed. For example:

// using global variables and no-error handling for brevity.

HINSTANCE theDll = NULL;
typedef void (__stdcall * FooPtr)();
FooPtr pfnFoo = NULL;
INIT_ONCE initOnce;

BOOL CALLBACK BindDLL(PINIT_ONCE initOnce, PVOID parameter, PVOID context)
{
    theDll = LoadLibrary();
    pfnfoo = GetProcAddress(dll, "Foo");

    return TRUE;
}

// Export for foo
void Foo()
{
    // Use one-time init for thread-safe lazy initialization
    InitOnceExecuteOnce(initOnce, BinDll, NULL, NULL)
    pfnFoo();
}

这篇关于为什么当我们获得实际的.dll实现时，我们还需要一个.lib存根文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！