从扩展DLL加载扩展DLL [英] Loading an Extension DLL From an Extension DLL

问题描述

我正在为一些第三方软件开发一个插件......这必须是扩展DLL的形式。



现在我想要不同的语言我的插件的版本所以我最初想把我的资源放在一个资源专用的DLL中，由插件DLL加载。这没关系，除非我需要手动交换我的资源句柄，这是一个很大的痛苦。



所以我想 - 我可以让我的资源DLL成为扩展DLL ？但是我不确定这是否会起作用 - 如果我从我的插件加载资源扩展DLL（即从扩展DLL中加载扩展DLL）我的资源是否正确地在链中？



或者这只是一个愚蠢的想法？我们总是可以将资源粘贴在插件中并拥有多种语言版本...

I'm developing a plugin for some third party software... which is necessarily in the form of an extension DLL.

Now I will want different language versions of my plugin so I initially thought to put my resources in a resource-only DLL, loaded by the plugin DLL. This is OK except I then need to keep manually swapping my resource handle which is a big pain.

So I then thought - can I make my resource DLL an extension DLL? But I'm not sure this will work - if I load the resource-extension DLL from my plugin (i.e., load an extension DLL from within an extension DLL) will my resources be in the chain correctly?

Or is this just a stupid idea? We could always just stick the resources in the plugin and have several languages versions...

推荐答案

目前尚不清楚扩展DLL究竟是什么意思（插件） -in DLL？），但这不是一个愚蠢的想法。但是一个非常愚蠢的想法是从中解决问题。您可以将任意数量的DLL加载到同一主机进程中;如果某些DLL不是直接加载，而是通过其他DLL加载并不重要。它可能是一些仅限资源的DLL，而不是一种非常罕见的做法。



另一件很重要的事，即插件或扩展机制本身。如果这只是静态链接的DLL，那根本不是问题。但是，必要的插件或扩展机制以与主机应用程序无关的方式工作。 DLL在运行时加载，并且在编译期间不知道此DLL的详细信息。应该存在主机和插件相互传递某些接口并通过它们调用函数的机制。 （在特殊情况下，它可以只是一种方式：主机可以调用DLL的功能;但另一种方式也会发生在一般情况下。）这样的插件或扩展架构可能是好的或坏的（有些是非常糟糕的，通过方式）。但你没有分享任何信息，所以我无法提出任何建议。 辅助DLL可以只是主DLL的实现细节，因此，对于主机应用程序来说，任何特殊情况都无关紧要。这种链的长度可能超过你所关注的三个步骤。这应该更合理，而不是病态。

-SA

It's not clear what exactly do you mean by "extension DLL" (plug-in DLL?), but this is not a stupid idea. But one pretty silly idea is making a problem out of it. You can load any reasonable number of DLL into the same host process; and it does not really matter if some DLL are loaded no directly, but through other DLLs. It could be some resource-only DLL, not a very rare practice.

The other thing is important, the plug-in or extension mechanism itself. If this is just statically linked DLL, it's not a problem at all. But essential plug-in or extension mechanism works in a way agnostic to the host application. The DLLs are loaded during runtime, and the detail of this DLL is not known during compile time. There should be the mechanism where the host and the plug-in pass some interface to each other and call functions through them. (In special cases, it can be one way only: the host can call the DLL's functions; but the other way also happens in general case.) Such plug-ins or extension architectures can be good or bad (some are amazingly bad, by the way). But you did not share any information, so I cannot advise anything certain. The "secondary" DLL can be just the implementation detail of the "primary" DLL, so, for the host application, it does not matter anything special. The length of such chain could be more then three steps you are concerned with. It's just should better be something reasonable, not pathological.

—SA

如果你'在MFC下运行（如标签所示）在你的DLLmain中使用 AfxSetResourceHandle



，找出你的语言想要，只加载该资源的dll，并使用上面的调用将MFC资源加载器指向它

if you're running under MFC (as the tag suggests) use AfxSetResourceHandle

in your DLLmain, work out what language you want, load that resource only dll, and use the above call to point your MFC resource loader at it

这篇关于从扩展DLL加载扩展DLL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！