Advertisement

DLL's vs Static libraries

Started by April 13, 2000 08:42 PM
25 comments, last by Void 24 years, 8 months ago
I''m at this point where recompilling gets so irritating that I''m thinking of rewriting everything in modules The question is : Should I write the modules as a static library or DLLs? I know DLLs are cool and reduce exeutable size and have dynamic loading, but what is the performance hit where the program has to load many dlls (like 20+) How should the dll''s be organized ( ie placed in the computer)?? Putting them all the in windows directory seems to be a bad idea (will overclutter the directory), and I don''t know how to link in a dll from other places without calling LoadLibrary. Static libraries have this disadvantage of recompiliing when the lib changes and you have to link in the correct C runtime libraries as the program (meaning I have to create 4 versions of the library) So anyone has suggestions on what is best?
Regardless of whether you use static or dynamic libraries, the build process is veritably the same. For static libraries, you simply link in the library. For dynamic libraries, you link in the import library (same process as static) and make sure the DLL is somewhere on the system path.

If your DLLs aren''t going to be needed by other applications (i.e., it''s not part of a popular SDK), then including them in your executable''s directory is just fine.

There really isn''t a performance hit, as you''re functions are being mapped to specific parts of memory just as if the DLL was statically linked.
Creativity is a bloody nuisance and an evil curse that will see to it that you die from stress and alcohol abuse at a very early age, that you piss off all your friends, break appointments, show up late, and have this strange bohemian urge (you know that decadent laid-back pimp-style way of life). The truly creative people I know all live lousy lives, never have time to see you, don't take care of themselves properly, have weird tastes in women and behave badly. They don't wash and they eat disgusting stuff, they are mentally unstable and are absolutely brilliant. (k10k)
Advertisement
Hmm... a lot of good questions...

There is a performance hit during load time. But, that is load time. One time hit. However, I would try to keep the number of DLLs down to a minimum.

If a DLL is located in the same directory as the executable, Windows will find it without any problems. Placing your DLLs in the windows directory is a bad idea IMHO.

During the build process, DLLs will greatly help your link time as long as you are not rebuilding and relinking your DLL all the time.

IMHO, I try to avoid DLLs as much as I can because it makes the package have less files that can get out of sync. However, if you are looking at selling a library, I would package it as a DLL.
wow.. quick replies..

I personllay prefer the static libraries too as it reduces the number of files in the system, and placing twenty dlls in the same directory seems messy to me.

The only thing against static libraries so far is I have to create a Debug/ Release, and Single/Multi Thread versions, whereas with a dll , I just create a debug/release version

DLL also has this advantage of auto loading and unloading at DLLMain, if I use the dll lib link method

Maybe MS should have a method of letting the program specify the dll load path without the need to call LoadLibrary.

Thanks..
Using DLLs also allows you to fix problems and possibly minimize the size/cost (download time, media pressing) of product update downloads/distro media.

Having a lot of DLLs isn''t necessarily messy. Take a look at Unreal Tournament''s system directory -- well over 20 DLLs if memory suits me.
Creativity is a bloody nuisance and an evil curse that will see to it that you die from stress and alcohol abuse at a very early age, that you piss off all your friends, break appointments, show up late, and have this strange bohemian urge (you know that decadent laid-back pimp-style way of life). The truly creative people I know all live lousy lives, never have time to see you, don't take care of themselves properly, have weird tastes in women and behave badly. They don't wash and they eat disgusting stuff, they are mentally unstable and are absolutely brilliant. (k10k)
revolver: U right man, but not so many dlls, only about 10..

say.. any one knows how to use lib linking but specify your own path for the dll??
Advertisement
I''m not 100% certain (I''ve not worked on a Windows platform for the past 5 years) but I think the loader will search your path for DLLS.

So you can put DDLs in the current directory (where you run the exe from)

/windows
/windows/system

or any where else on the path

The loader will search in the order I''ve given them
I''m assuming that you want to do the following:

c:\myprogram\myprogram.exe USES
c:\myprogram\mydlls\mydll.dll

If myprogram.exe statically links to mydll.dll you can use the PATH environment variable to tell Windows where to look for the DLL.

SET PATH = %PATH%;c:\myprogram\mydlls

When your program calls an exported function Windows will search KERNEL32.DLL and USER32.DLL first, the directory of the current process, the current directory, the Windows system and Windows root directories and finally the directories listed in the PATH environment variable.

Just remember, when you set your PATH variable if the directory you specify has spaces, make sure you enclose it in quotes.

Ex.

SET PATH = %PATH%;"c:\program files\myprogram\mydlls"

-----------------------------^ space

Its similiar to how you change directories under the Windows 9x DOS prompt.

cd "program files"

or

cd "progra~1"

Same thing

Hope this helps you.

Dire Wolf
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
quote: Original post by Void

revolver: U right man, but not so many dlls, only about 10..

say.. any one knows how to use lib linking but specify your own path for the dll??

Yes, I like the idea because it would be posibble to put diferent applications using the same DLLs in their own directory each, within a parent directory, and then load the DLLs from each application''s current directory''s parent directory like "..\TheDLL.DLL", etc.

For now, I guess we will have to settle by using LoadLibrary and then taking a pointer to a jump table.

Just my $.02
Topgoro
We emphasize "gotoless" programming in this company, so constructs like "goto hell" are strictly forbidden.
There is one alternative if you are using MSVC++ 6. That is using the delayed loader and specifing your own helper routine to load the library from where you need it. (All the helper routine does is call LoadLibrary and GetProcAddress).

Here is a web address from MSDN that talks a little about the delay loader.

http://msdn.microsoft.com/library/periodic/period98/1298_HOODLAYO_HOOD.htm

Tim

This topic is closed to new replies.

Advertisement