26 DLL's loaded for skeleton windows app! WHY?

[Damos]

i've been working on mixing 'C' & assembly and trying to get a small footprint for the .exe. I have succeeded my skeleton windows app is only 5k.
what is astonishing is in the output pain of visual studio 2008 it display's the loading of 26 DLL's whereas by my reckoning there should only need to be user32.dll & kernel32.dll.

It even show mscrt.dll in the display even though I have gone to great lengths to avoid using any of the c runtime. I have excluded all standard libs from my build.

I am thinking that there is a dependancy in some dll's on other dll's.

the other strange thing is that when I examine the dll's loaded when run through ollydbg it only list 16 DLL's (but still mscrt.dll).

what do you thinks going on here?

i've just tried olly on the 'minimum' example program (simply displays a message box) that also loads up 16 DLL's.

I'd really appreciate some insight into this. can any one help? :bg

[redskull]

IIRC, the only "mandatory" DLL's that every process gets are ntdll.dll and kernel32.dll, which are both required for creating the process (certain functions need be called from the "P.O.V." of your program during CreateProcess, to register with CRSS, etc).  However, each DLL you link to gets a chance to link it it's own libraries, which can link to others, etc, etc.  So even though *you* only link to user32.dll, user32.dll links to GDI32, ADVAPI, MSIMG, etc.  In turn, each of *those* link to others.  specifically, POWRPROF and WINSTA were both (presumably) written in C, and link to MSVCRT.  A good tool to investigate this is DEPENDS.EXE, which shows everything in a nice tree form.  Try examing a Java or .NET program, and 26 won't seem so bad  :bg

Other than not using the libraries altogether, there's not much you can do about it; at the same time, though, it doesn't really cost too much overhead to use them.  Since most programs use the 'big three' (user, kernel, gdi), there is a VERY good chance they are already loaded in memory, along with all of their dependents, and so the already-loaded modules simply get 'mapped' into your process, which is relatively inexpensive.  If your programs never call them, then they never get "loaded" in the normal sense.  The downside is that you get less address space to play with, if you are working up around the 2G limit

-r

[Damos]

Thank you for your response redskull, you have confirmed some of my supsitions.
You have also shown me something new: that dll's are not 'loaded' in the conventional sense but are simply mapped to my process. this is nice to know.
but whilst doing my research in making small exe's it was suggested that dynamically linking to mscrt.dll would require a load to memory therefore slowing down the load of the process in question. but, like you say this dll is probably already in memory so what's the fuss. the article 'tinyc.lib' was basically all about avoiding the mscrt.dll.
thanks again :bg

[Damos]

i've just used the depend.exe and it has confirmed exactly as you predicted. my proggy only has a dependancy to kernal32.dll and user32.dll, but user32.dll has dependancies to various dll's which in tern have dependancies. and it seems that all the process's that i have examined have a dependancy to mscrt.dll.
thanks again. :bg

[redskull]

Thank you for your response redskull, you have confirmed some of my supsitions.
You have also shown me something new: that dll's are not 'loaded' in the conventional sense but are simply mapped to my process. this is nice to know.
but whilst doing my research in making small exe's it was suggested that dynamically linking to mscrt.dll would require a load to memory therefore slowing down the load of the process in question. but, like you say this dll is probably already in memory so what's the fuss. the article 'tinyc.lib' was basically all about avoiding the mscrt.dll.
thanks again :bg

For fun and excitement, read up on the LoadLibraryEx function; instead of linking to user32.dll during startup, you load the library at runtime, search out the address of the messagebox function as part of your code, and then call it indirectly.  This method can bypass the DLLmain startup code and the the loading of other modules, at the expense of simplicity.

-r

[Vortex]

Hi Damos,

Another method to get the list of imports :

Code Select Expand

\masm32\bin\dumpbin.exe /IMPORTS yourexecutable.exe

[Ghandi]

You can also use LordPE, a PE Editor, found easily with Google. Then you can also examine anything else you want to in the PE header. CFF Explorer comes to mind as well, as it is excellent for PE editing and viewing.

HR,
Ghandi