加载DLL函数的更好方法? [英] A better way to load DLL functions?

查看:68
本文介绍了加载DLL函数的更好方法?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我觉得有一个比在typedef中具有数百个签名,然后通过GetProcAddress加载指针的方法好得多的方法。据我所知,在加载DLL函数时,这是最简单的方法,但是很脏。



加载DLL函数的方式是否更简单一些?具体来说,有大量的Winapi和工具帮助库功能吗?我知道您可以包含一个.lib,但是我觉得那样会引起不必要的膨胀。我也无法访问源代码(尽管Jason C提到可以将.dll转换为.lib)。



我一直在寻找代码库。我觉得主要障碍是处理具有不同签名的功能。还是这正是每个人都使用typedef而不是一些幻想循环加载其DLL函数的原因吗?

解决方案

链接到.lib文件的膨胀(通过膨胀,我假设您的意思是可执行文件上有一些额外的kB,您知道...)如果您将其用于避免处理数百个GetProcAddress调用的便利。 :)



不太清楚幻想循环的含义; 在此上下文中使用的typedef 的作用类似于标头中的声明-它们为编译器和人类读者提供有关所调用函数签名的信息。



这里有一些工具可以从.dll生成.lib。但是您仍然必须有一个标头,以声明要调用的函数,以便编译器知道您在做什么。本质上,为.dll生成的.lib只是一个存根,它会加载DLL并为您获取函数地址。不同的API,但本质上是相同的。但是,在大多数情况下,我不会说避免对函数进行typedef /声明是执行此类操作的足够动力。例如。您可以公开一个功能,例如:

  void PerformAction(LPCSTR操作,DWORD参数); 

根据您的操作,使PerformAction的实现有所不同。在与您的帖子无关的某些情况下,这当然是合理的,但对于您正在描述的问题,这实际上不是一个适当的解决方法。



您几乎只需要处理它。使用声明创建标头并生成存根.lib,或者使用typedefs创建标头并使用LoadLibrary / GetProcAddress。前者可以为您节省一些打字时间。后者可以让您处理不存在DLL的情况,或在设计时加载未知的DLL(例如,另一个答案中提到的插件)。


I feel like there's a much, much better way than just having hundreds of signatures in typedefs, and then loading pointers by GetProcAddress. As far as I know, it is the easiest -- but dirty -- when it comes to loading DLL functions.

Is there a less messy way to load DLL functions? Specifically, a large amount of Winapi and Tool Help library functions? I know you can just "include a .lib," but I feel like that would cause unnecessary bloat; nor do I have access to the source code (although Jason C mentioned it is possible to go from a .dll to a .lib).

I was looking to code a library for this. I feel like the major roadblock is dealing with functions that have varying signatures; or is this precisely the reason why everyone uses typedefs instead of "some fanciful loop" to load their DLL functions?

解决方案

The "bloat" of linking to a .lib file (by "bloat" I'm presuming you mean a few extra kB on the executable, which, ya know...) isn't "unnecessary" if you're using it for the convenience of avoiding dealing with hundreds of GetProcAddress calls. :)

Not quite sure what you mean by "some fanciful loop"; the typedefs used in this context serve a similar purpose to declarations in a header -- they provide the compiler and the human reader information about the signature of the function that is being called. One way or another, you have to provide this.

There are tools out there to generate a .lib from a .dll; but you'll still have to have a header declaring the functions you are calling so that the compiler knows what you're doing. Essentially, a .lib generated for a .dll is just a "stub" that loads the DLL and gets the function addresses for you. Different API, but essentially the same.

The only way around it is to design your DLL interface differently so that you don't have as many functions to deal with. However, in most cases I would not say that avoiding typedefs/declarations for functions is sufficient motivation to do something like this. E.g. you could expose exactly one function like (for example):

void PerformAction (LPCSTR action, DWORD parameter);

And have your implementation of PerformAction do something different depending on "action". That is certainly reasonable in certain situations that are unrelated to your post, but it is not really an appropriate "workaround" for the "problem" you are describing.

You pretty much just have to deal with it. Either create a header with declarations and generate a stub .lib, or create a header with typedefs and use LoadLibrary/GetProcAddress. The former will save you some typing. The latter lets you handle cases where the DLL is not present, or load DLLs that are unknown at design time (e.g. plugins as mentioned in another answer).

这篇关于加载DLL函数的更好方法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆