I hate having more than one file in my progs, but some times I need a DLL. Could I package an entire DLL into the executable as a resource, dump it at run time into a file (i.e., c:\windows\system\temp.dll) and then call it with the GetProcAddress routines? The file would then be deleted before exiting. This sounds pretty straightforward to me.
Posted on 2002-10-30 11:50:58 by rdaneel
Hi!

You can try the Pebundle tool from Collake software

http://www.collakesoftware.com/PEBundle/CSPEBundle.htm

Regards,

Vortex
Posted on 2002-10-30 12:10:40 by Vortex
Embedding the dll to the main application:Solution by doing the job manually

First,we need a binary to coff object converter to embed our dll as binary data. The ZIP file (attachment) contains the bin2o tool from f0dder (Thanks f0dder!)
You can get this tool from:

http://f0dder.didjitalyphrozen.com/dl/bin2o_04.zip

The dll is linked "staticaly" to the executable.We extract it at runtime,call the dll function,and delete it before terminating all the job. The "usedll" example calls our dll function which displays a message box.
Finally,I have included a copy of the executable packed with UPX.For this,check the folder "Packed"
(Size reduction=%45)
The UPX packer available from:

http://upx.sourceforge.net

Please check the build.bat file to see the steps of operation.
Let me know your comments\suggestions.

:alright:

Regards,

Vortex

Here is the source code for the executable (usedll.asm):

.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib

extern mydata:byte

.data
library db "mydll.dll",0
myfunc db "msgbox",0

.data?
hLib dd ?
func dd ?
hFile dd ?

.code
start:
invoke _lcreat,addr library,0
mov hFile,eax
invoke _lwrite,hFile,addr mydata,3072
invoke _lclose,hFile

invoke LoadLibrary,addr library
mov hLib,eax
invoke GetProcAddress,hLib,addr myfunc
mov func,eax
call
invoke FreeLibrary,hLib
invoke DeleteFile,addr library
invoke ExitProcess,NULL

end start
Posted on 2002-10-31 01:31:25 by Vortex
rdaneel,

Either of the suggestions will work OK for you, f0dder's tool makes an OBJ file that contains the BYTE data and Jeremy Collake's tool does the loading of the DLL into memory from within the EXE file but there is also a tool in MASM32 that will convert the DLL into DB format BYTE data that you store in your code and just write it to disk when you want to run the DLL.

It is called "bintodb.exe" and is in the MASM32 directory.

Regards,

hutch@movsd.com
Posted on 2002-10-31 16:33:47 by hutch--
You are prepared to go through that process just because *you* hate having more than one file??!!

It is your app, so do what you like with it. But why go against an established programming standard that is known and accepted by the end user?
Posted on 2002-10-31 18:34:54 by sluggy
PEBundle seems a ncier way to do it, since you don't have to go through the disk, but it seems you have to buy it...

The Svin has a post you might find interesting:
http://www.asmcommunity.net/board/index.php?topic=8726

Of course, one purpose of a DLL is to allow code to be shared, and by keeping the DLL in the EXE you prevent code from being shared easily. You *might* also encounter some problems with running two instances of your program since you might try to write to a file that's already open because you're running it.
Posted on 2002-10-31 20:56:21 by AmkG
yes, i think dll's are really disturbing... especially for asm progs. all these
methodes explained above are okay but i think the best solution would be
to write your own stuff instead of use anotherones code. there are only a
few cases where you must *really* relate on a dll, hooks, ring0 in nt, and
all the other workarounds. oh and then all this licensing crap... you should
ask what it is - what's inside this dll and maybe someone has got an asm
implementation for it. just a thought... good luck anyway
Posted on 2002-11-01 05:26:13 by mob
how about exe in exe, it's like exe packer. packed, load in memory and execute it without create any file ????
helpp me ??
thanks
Posted on 2003-03-16 23:59:37 by irwan
What is the advantage of this method ?
Why not use a DLL ?
Posted on 2003-03-17 00:59:55 by DarkEmpire
I have it working now. I chose to just put the dll in the resource file as an rcdata entry. Here is the code I use to dump it at run time and get the function locations:



;;;| Dump the keyhook dll to a temp file
mov edx, 0
mov dx, DLL_KEYHOOK
invoke FindResource, hInstance, edx, RT_RCDATA
mov hRcDLL, eax
invoke LoadResource, hInstance, hRcDLL
mov hResDLL, eax
invoke CreateFile, ADDR libKeyHook, GENERIC_READ+GENERIC_WRITE, FILE_SHARE_READ+FILE_SHARE_WRITE, \
NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL
mov hFile, eax
invoke SizeofResource, hInstance, hRcDLL
mov sizeResDLL, eax
invoke LockResource, hResDLL
mov pResDLL, eax
invoke WriteFile, hFile, pResDLL, sizeResDLL, ADDR BytesWritten, NULL
invoke CloseHandle, hFile
;;;| Load up the dll and find it's functions
invoke LoadLibrary, ADDR libKeyHook
mov hLibKeyHook, eax
invoke GetProcAddress, hLibKeyHook, ADDR procInstallHook
mov InstallHook, eax
invoke GetProcAddress, hLibKeyHook, ADDR procUninstallHook
mov UninstallHook, eax


Then at the end of WinMain I just do this to clean up:



call UninstallHook
invoke FreeLibrary, hLibKeyHook
mov ecx, 0
@3: inc ecx
cmp ecx, 100
je @4
invoke DeleteFile, ADDR libKeyHook
cmp eax, TRUE
jne @3
@4:


This is for a universal OEM key enabler program. It will work with any keyboard that has those funky OEM keys on it(i.e., Mail, Shop, Internet, Search). I needed a way to hook the keyboard, but still only distribute one file. Anyway, it is working well for me. I guess for big dll's with lots of exports you would need it automated somehow. Nobody wants to store 50 different proc addresses.
Posted on 2003-03-17 07:39:40 by rdaneel
Nice work:alright:
Posted on 2003-03-17 14:21:20 by Vortex
Umm, I find it much more comfortable to use MASM's bintodb tool:

? convert given.dll to given.inc
? include given.inc
? (GetTempDir) / CreateFile / WriteFile / CloseHandle
? LoadLibrary


Also, using a DLL doesn't definitely mean it's someone else's work

:rolleyes:


aweX <-
Posted on 2003-03-19 12:05:43 by aweX
ugly ugly ugly. just for some very questionable "aesthetics", you're doing all this extra work? including DLL and dumping it to disk? geesh. manually loading it (directly from memory without dumping), or using PEBundle is better... but still, if you got to use a DLL, do the proper thing and include it next to your application. or at least be sure you understand all of the bad things that come from your method. the "packing, data handling, stuff" article at my site has a few rants about this.
Posted on 2003-03-19 16:03:50 by f0dder

ugly ugly ugly.


Yes, but it *is* fun to do :grin: :grin:
Posted on 2003-03-19 16:29:35 by Kayaker
sure, it's fun and you learn from doing it - which is enough reason to play with it. but keep crap like this from production code.
Posted on 2003-03-20 01:53:00 by f0dder
f0dder,

Sometimes,practical solutions are prefered to aesthetics. ;)

Regards,

Vortex
Posted on 2003-03-20 02:44:10 by Vortex
Sometimes, you have to ask yourself why you are coding. For the practical use of your app or for the holy
theory only. After all, we know that some specific persons here really like to rant and disagree with any-
thing being 0.01% out of the ordinary.
But why not leave the people their coding style? They will change it if they feel it's inappropriate. But as
long as a code works fine on all systems, why hate it?

Talking about EXE's carrying DLL's, it's indeed a bit uncommon, but it's just more user-friendly if one
doesn't have to mess with extra DLLs putting them here or there. Or do you like apps like ICQ that
come with approx 30 DLLs ??

As long as you, the programmer, know what you're doing and take the necessary safe-guards or check
for compatibility, you're fine.

Oh and if you really can load a DLL directly from mem, then the dumping is not even needed ... makes it
a lot easier. I don't know such a LoadLibraryFromMem() function though ... :rolleyes:


aweX <-
Posted on 2003-03-20 04:16:36 by aweX
Problem is, people think that some things are "neat", without thinking about (or knowing) the consequences. Sure, it might feel "neat" for the programmer not having to show he's using fmod.dll (or whatever), but it's less optimal for a number of reasons. First, there's the additional code overhead of dumping and loadlibrary+getprocaddress, when you could just implicitly link to the import library. Then there's using additional disk space while app is running (sure, this will usually be a tiny amount, but it's more slop nonetheless). Using more disk cache. More work on second load of app (since you're probably re-dumping the DLL, windows can't just use a cached copy).


Talking about EXE's carrying DLL's, it's indeed a bit uncommon, but it's just more user-friendly if one doesn't have to mess with extra DLLs putting them here or there. Or do you like apps like ICQ that come with approx 30 DLLs ??

Including DLLs doesn't really have anything to do with user friendlyness. Users don't deal with the DLLs, the installer/uninstaller does. ICQ is a horrible application, but it would be even more horrible if it had the 30+ DLLs included in the EXE and dumped them on every program startup.


As long as you, the programmer, know what you're doing and take the necessary safe-guards or check for compatibility, you're fine.

Then please _DO_ know what you're doing.


Oh and if you really can load a DLL directly from mem, then the dumping is not even needed ... makes it
a lot easier. I don't know such a LoadLibraryFromMem() function though ...

It isn't really too hard to write yourself... well, for the DLL types that would be "feasible" to include in the exe anyway.
Posted on 2003-03-20 04:33:49 by f0dder
I wonder if anyone has tried appending the DLL to the EXE file then calling it that way. I am not sure it can be done but it may be worth a try.

Getting the starting offset on the disk file is no big deal and it means you both have the DLL and its attached to the EXE file so its a single file.

Regards,

hutch@movsd.com
Posted on 2003-03-20 04:46:49 by hutch--
for obvious reasons (relocs, unitialized imports, . . .) that would only work for very simplistictic DLLs.
Posted on 2003-03-20 04:50:20 by f0dder