## Recommended Posts

##### Share on other sites
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?

##### Share on other sites
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.

[Edited by - moeron on May 22, 2007 1:03:02 PM]

##### Share on other sites
Quote:
 Original post by moeronI'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'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().

##### Share on other sites
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.

##### Share on other sites
Quote:

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 iMalcSo 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 ).

##### Share on other sites
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.

##### Share on other sites
Well I've got my little test app to work with delay-loaded dlls from memory. After doing some reading I found...

#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]

## Create an account

Register a new account

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627661
• Total Posts
2978496

• 10
• 12
• 22
• 13
• 33