Delay-load dll from memory
I know it is possible to delay-load a dll using VC 2005 - and I'm aware of a way to load a DLL from memory using MemoryLoadLibrary from the CRT. However, is there anyway to combine these two methods?
The basic reasoning behind this is I have an application that uses dll "x" - in the application this dll is wrapped up in some license protection scheme. Now I have a couple other little "helper" tools that are free-of-charge and should be distributed freely. However, these helpers also depend on dll "x". But I do not need these to get the protection scheme. I shouldn't really distribute the non-protected "x" dll or someone could realize that if he copies our unprotected "x" over the protected "x" it will circumvent the protection scheme.
So thats what led me to the idea of loading the dll from memory. But that won't work on its own since I link to an import lib ( and have to ). Delay-loading will get around the import lib issue - but that creates its own functionality to wrap a LoadLibary - GetProcAddress when accessing the functions from the delay-loaded dll. I guess if I could just somehow replace the LoadLibrary to a MemoryLoadLibrary call then all would be fine - but so far I've not seen anyone discuss such an implementation.
I'm leaning toward a solution that isn't super-complex as I am on a bit of a deadline to figure something out. Thanks!
I've never heard of MemoryLoadLibrary, and I can't find it anywhere in the MSDN. I thought there was some reason there's no way to load a DLL from memory (Although I know you can do it manually, but it's incredibly horrible and involves allocating the memory for the DLL, thunking up imports, calling DllMain, etc all yourself, probably isn't portable and probably won't even work on Vista).
So, assuming MemoryLoadLibrary() is the same as LoadLibrary() but takes a pointer to a DLL in memory; surely delay loading is resundant, since you'll need to use GetProcAddress yourself anyway?
So, assuming MemoryLoadLibrary() is the same as LoadLibrary() but takes a pointer to a DLL in memory; surely delay loading is resundant, since you'll need to use GetProcAddress yourself anyway?
Yeah I'm not sure. My "knowledge" on the subject is based solely off a few hours googling and looking at some articles. I was kind of hoping someone else has already went through this before. I'm linking to the dlls import library - so I was under the impression I would need the delay-load to make it so my application wouldn't automatically load the dependency so I could load it from memory.
[edit]
I misread the article, MemoryLoadModule is not CRT - your right.
[Edited by - moeron on May 22, 2007 1:03:02 PM]
[edit]
I misread the article, MemoryLoadModule is not CRT - your right.
[Edited by - moeron on May 22, 2007 1:03:02 PM]
Quote:Original post by moeronIf you're linking statically, then you'll need the .dll file as a file, in which case there's no need for any form of LoadLibrary().
I'm linking to the dlls import library - so I was under the impression I would need the delay-load to make it so my application wouldn't automatically load the dependency so I could load it from memory.
If you want to do runtime linking (And get delay loading for free), then don't link to the .lib file and use [Memory]LoadLibrary(), and GetProcAddress().
So what is the problem with simply setting the project up to delay-load the secondary DLL? It's a piece of cake to do.
Quote:Original post by Evil Steve
If you're linking statically, then you'll need the .dll file as a file, in which case there's no need for any form of LoadLibrary().
If you want to do runtime linking (And get delay loading for free), then don't link to the .lib file and use [Memory]LoadLibrary(), and GetProcAddress().
If I could ditch the import lib then I could use the code I found for the MemoryLoadLibrary with no problem. But, unfortunately, it isn't an option for me due to the wide scope of usage of functionality from this particular dll. It would be a pretty large undertaking at this point to stop relying on the import lib. I guess I'll have to come up with some other way to avoid my licensing issues.
Quote:Original post by iMalc
So what is the problem with simply setting the project up to delay-load the secondary DLL? It's a piece of cake to do.
Delay loading isn't difficult - its getting delay-loading to work with a library loaded from memory. The actual goal I'm going for is being able to keep a dll hidden in memory ( see OP for full explanation ).
Well, with the .lib dependancy, the exe is linking to the file (on disk) already - including the .lib tells the linker "There is a DLL called X.dll that I want you to load from disk when I start up". The only way to remove that reference to the DLL on disk is to use runtime linking - in which case there's no need for delay loading.
Well I've got my little test app to work with delay-loaded dlls from memory. After doing some reading I found...
The DelayImp.lib brings in a function called "__delayLoadHelper2" (and a couple others) which wraps the LoadLibrary / GetProcAddress stuff. This stuff is found in "delayhlp.cpp". So I just made my own version of this file and removed "DelayImp.lib" as a dependency. My little tester app works fine - but I still have the uncomfortable feeling that comes from messing with crap I don't fully understand. Even though I have successfully delay-loaded a dll from memory- I'm thinking I still might just throw in the towel and find a better solution. I'm sure me hacking around in that stuff is bound to cause issues on some Window's platforms...Oh well.
[Edited by - moeron on May 22, 2007 5:55:22 PM]
#include <DelayImp.h>#pragma comment(linker, "/DelayLoad:DLLTest.dll" ) // delay load my test dll#pragma comment(lib, "DelayImp.lib") // microsoft helper funcs for delay loading
The DelayImp.lib brings in a function called "__delayLoadHelper2" (and a couple others) which wraps the LoadLibrary / GetProcAddress stuff. This stuff is found in "delayhlp.cpp". So I just made my own version of this file and removed "DelayImp.lib" as a dependency. My little tester app works fine - but I still have the uncomfortable feeling that comes from messing with crap I don't fully understand. Even though I have successfully delay-loaded a dll from memory- I'm thinking I still might just throw in the towel and find a better solution. I'm sure me hacking around in that stuff is bound to cause issues on some Window's platforms...Oh well.
[Edited by - moeron on May 22, 2007 5:55:22 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement