Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Void

DLL's vs Static libraries

This topic is 6695 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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??

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!