为什么当我们获得实际的.dll实现时,我们还需要一个.lib存根文件?

前端之家收集整理的这篇文章主要介绍了为什么当我们获得实际的.dll实现时,我们还需要一个.lib存根文件?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我想知道为什么连接器不能通过查看具有实际实现代码的实际.dll文件中的信息来完成他们的工作?我的意思是为什么接口人仍然需要.lib文件来做隐式链接

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

有没有一个可以做隐式链接只使用.dll没有.lib stub /代理文件

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

任何帮助是赞赏,很多谢谢:)

geeko

我可以想到几个原因。

>使用.lib文件意味着您可以构建与您的系统不同的DLL版本,只要您安装了正确的SDK。
>编译器连接器需要支持跨平台编译 – 您可能正在32位平台上构建64位目标,反之亦然,并且没有正确的架构DLL存在。
> .lib文件使您能够“隐藏”实现的某些部分 – 您可以具有不显示在.lib中但可通过GetProcAddress发现的私有导出。您也可以执行序数导出,在这种情况下,它们没有导出友好的名称,但在.lib中将会有一个友好的名称
>本机DLL没有强名称,所以可能会拿起错误的DLL版本。
>最重要的是,这项技术是在20世纪80年代设计的。如果它是今天设计的,那么它可能会更接近你所描述的内容 – 例如,.NET只需要引用目标程序集,并且拥有使用它所需的一切。

我不知道有什么办法完全与DLL的隐式连接 – 快速搜索显示了几个工具,但我没有使用任何一个。

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

// 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();
}

猜你在找的Windows相关文章