Can one include a DLL directly in an EXE?
Author
I have a DLL that I would like to link statically to, but cannot. It's not too big of a deal, but I would like to find some way to accomplish it.
I tried including it as a resource (Win32 program, VC++ .NET), but couldn't get that to work. Is there anyway to have the dll sort of "appended" to my exe in such a way that LoadLibrary can find it?
Or am I just gonna have to learn to cope?
EDIT: I am not the one calling the LoadLibrary directly, it is in the .lib file that is linked, so I can't simply use FindResource().
[edited by - Rick Scott on March 3, 2003 1:41:14 PM]
Does the DLL contain code?
If it does, then it **requires** runtime linking of the functions which are exported in the export .lib file into the client executable code AND requires any modules it itself depends on to be loaded and linked. LoadLibrary is what usually does this.
If you _really_ need to do this (and I suspect you really don''t!), then you could use the ImageHlp library on the DLL since a DLL is in PE format (the same as a .exe) and resolve all the imports and exports manually, then simulate the process and thread attach/detach messages to the exported DllMain.
If it''s the "DLL not found" type errors which are your _real_ problem and the DLL is data only , then don''t link with the .lib file and then use the resource calls to get at what is inside the DLL OR you can use /DELAYLOAD (search MSDN) to get in before the error.
But as mentioned above this WILL NOT work if the DLL contains code. As soon as you call anything in the DLL you''ll get an access violation or page fault.
An alternative option is to append the DLL to your .exe as you''ve suggested, DON''T link with it''s .lib file, then when your program starts, copy the appended DLL to a temporary folder and use LoadLibrary & GetProcAddress to load and link the DLL as usual.
BTW: the whole point of DLLs is to have them separate from your .exe - if it doesn''t need to be a DLL, don''t make it a DLL!!. Unless of course you''re trying to hide the fact that you''re using a 3rd party DLL. In which case you may also be dodgy legal territory.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
If it does, then it **requires** runtime linking of the functions which are exported in the export .lib file into the client executable code AND requires any modules it itself depends on to be loaded and linked. LoadLibrary is what usually does this.
If you _really_ need to do this (and I suspect you really don''t!), then you could use the ImageHlp library on the DLL since a DLL is in PE format (the same as a .exe) and resolve all the imports and exports manually, then simulate the process and thread attach/detach messages to the exported DllMain.
If it''s the "DLL not found" type errors which are your _real_ problem and the DLL is data only , then don''t link with the .lib file and then use the resource calls to get at what is inside the DLL OR you can use /DELAYLOAD (search MSDN) to get in before the error.
But as mentioned above this WILL NOT work if the DLL contains code. As soon as you call anything in the DLL you''ll get an access violation or page fault.
An alternative option is to append the DLL to your .exe as you''ve suggested, DON''T link with it''s .lib file, then when your program starts, copy the appended DLL to a temporary folder and use LoadLibrary & GetProcAddress to load and link the DLL as usual.
BTW: the whole point of DLLs is to have them separate from your .exe - if it doesn''t need to be a DLL, don''t make it a DLL!!. Unless of course you''re trying to hide the fact that you''re using a 3rd party DLL. In which case you may also be dodgy legal territory.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Author
I don''t really HAVE to do it, and it is for use with a 3rd party library. The library was free, and I plan to give credits directly to the creator in my credits and in the readme file (as well as a link on my website), so I''m not trying to hide the DLL per se, just make it easier to move around with my EXE 
I guess the short answer is: No
Oh well. Thank you muchly!
I guess the short answer is: No
Oh well. Thank you muchly!
Thought about this problem recently.
1) coding your own PE loader for this is probably overkill.
2) appending to .exe, writing to disk and LoadLibrary as S1CA suggests is no problem.
3) is an open-source reimplementation of the DLL a possibility?
4) PEBundle does 1) and 2), but is not free in either sense of the word.
5) crazy idea from Svin (greetz): load your .exe as a DLL - Link. For this purpose, though, it''ll be a huge mess/pain, and I see no significant benefits vs. 2).
1) coding your own PE loader for this is probably overkill.
2) appending to .exe, writing to disk and LoadLibrary as S1CA suggests is no problem.
3) is an open-source reimplementation of the DLL a possibility?
4) PEBundle does 1) and 2), but is not free in either sense of the word.
5) crazy idea from Svin (greetz): load your .exe as a DLL - Link. For this purpose, though, it''ll be a huge mess/pain, and I see no significant benefits vs. 2).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
