• Advertisement

Archived

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

DLL's vs Static libraries

This topic is 6513 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
What is wrong with the PATH environment variable? He stated that he did not want to use LoadLibrary and using the PATH variable is the right way to go. It works under both Windows 9x and NT/2000.

BTW The delayed loading feature is REALLY nice for creating 9x/2000 programs that require different underlying DLLs.

Dire

Share this post


Link to post
Share on other sites
Yes..the environment path is nice.. but how do I add the path in within the program??

As far as I know, The "set" command is accessed by command prompts.

Do I have to use WinExec or maybe make a dos script??

Thanks for all the answers..

..

Share this post


Link to post
Share on other sites
If I may ask a question about WinExec...I made a playlist manager for Winamp, and when I use WinExec to run Winamp, I get the hourglass cursor and my program stops receiving messages for an irritating 2-3 seconds (still unresponsive after winamp has already loaded and gone idle). Why is that? Shouldn''t WinExec return before that?

-J

Share this post


Link to post
Share on other sites
I have heard if you find a error in a dll you can fix it. by just editing the dll and distributing it. So if I were you I'd go with dlls but keep it low. It well be easier to fix errors this way after you distribute the game or maybe have a look at COM.

Edited by - ARCHIGAMER on 4/19/00 6:35:28 AM

Share this post


Link to post
Share on other sites
There seem to be a lot of conflicting terms here...so I'll try to clarify the different types of libraries you can use and the situations in which you can use them. (Someone let me know if I'm wrong here.)


    1) Static Library (.LIB) - Just a lib that basically gets compiled right into your program code. You cannot replace this without re-compiling your executable (obviously). However, versioning is never a problem for the end user of your executable.

    2) Dynamic Library (.DLL) - This one can be loaded and unloaded dynamically, that is, at run-time. You can freely update this file, as long as the names of the functions remain the same. No static linking is required, but you must use LoadLibrary and GetProcAddress to call functions, and you must export C code.

    3) Shared Library (.LIB and .DLL) - This is a mix between the first two, that inherits some properties of both. First, the project is created as a .DLL, but functions and classes may be exported. You must re-compile your executable if the .LIB file changes between builds of the .DLL file.



Static libraries are definitely the easiest for small projects where the code will only be used once. DLLs are better for maintenance, but you must be careful not to change the function names. Shared libraries are very tricky to distribute, as they must be bug-free in the release build (the build that will be distributed), or else you force the .LIB's users to re-compile every time you squash a bug in the .DLL. The only library type that does not require a header file (to use the code, that is) is the dynamic library.

Second comparison is the code size that several programs will take up on the end user's hard drive. With a static library, a copy of the library is found in each executable that uses it, so if you have 20 programs installed using your static lib, and your static lib is 350 KB, you now have approximately 7 MB being taken up by your lib. With a dynamic library, this is never a problem. The DLL is stored (typically) in the Windows or Windows\System directory, and then loaded by each program, while Windows keeps one copy of the code in memory (basically). Same thing with shared libraries, except you've got the versioning problem. So, for the last two types, with 20 programs and a DLL size of 350 KB, you use only approximately 350 KB on the end user's hard disk.

Third comparison is what you can export from the libraries. Static libraries can export classes, no problem. Dynamic libraries can only officially export C functions, but that can be easily worked-around. Shared libraries export classes just as easily as static libraries.

To do classes with a dynamic library, you use an abstract base class in the executable (the abstract class takes up almost no code because of pure virtual functions). Then, take the .h for that abstract base class and use it in the dynamic library's project, deriving your own class from it. Simply build a single C function that gets a pointer to the class from the DLL, and you can use that function from the executable to get a pointer to the class located in the DLL. Simply LoadLibrary and GetProcAddress to get the address of that C function, then call it to get the pointer to the interface. Voila! virtual functions are now the link between your executable and the code in the DLL.

Fourth comparison is updating files. With the static lib, you must update the whole executable (unless you have some sort of patching utility). With the dynamic lib, simply copy and paste the new DLL files on the old ones, and the executable will work. With shared libs, you must update the shared file, but make sure that the .LIB didn't change between builds.



- null_pointer
Sabre Multimedia


Edited by - null_pointer on 4/19/00 8:29:45 AM

Share this post


Link to post
Share on other sites
quote:
With a dynamic library, this is never a problem. The DLL is stored (typically) in the Windows or Windows\System directory, and then loaded by each program, while Windows keeps one copy of the code in memory (basically).


Umm? Ew! DLLs should never be put in any of the windows directories. Even things like MFC.

If you write your own DLLs, put them in the same directory as the executable, or in a subdirectory.

Windows will search for DLLs by doing this:
-Is it in the current directory?
-Is it in the windows directories (windows, windows\system, windows\system32?
-Is it somewhere else in the path?

The current directory might not be the same place as the executable - this can happen if you set up a shortcut, and don''t fill in the "start in" field.

Putting dlls in the windows directories, or modifying the DOS path, is against the rules (even if you''re allowed to do it). It can cause so many horrible, evil problems that to suggest doing so makes me feel ill.

If you want to put DLLs somewhere, create a registry entry which says where such things are . This is the same for a single product as it is for multiple products using shared dlls.

On a slightly less nasty point, null_pointer - .lib and .dll files are shared libraries - a shared library isn''t some special form of a .lib or .dll.

Shared library is just a term used to describe the fact that .libs and .dlls provide ways to share your code/resource libraries.

TheTwistedOne
http://www.angrycake.com

Share this post


Link to post
Share on other sites
Hi all.

NullPointer
quote:
Fourth comparison is updating files. With the static lib, you must update the whole executable (unless you have some sort of patching utility). With the dynamic lib, simply copy and paste the new DLL files on the old ones, and the executable will work. With shared libs, you must update the shared file, but make sure that the .LIB didn''t change between builds.



Well, while developing a DLL I made a Test.exe which simply calls a function In that DLL called "SelfTest", so I did not have to go back and forth testing the DLL, which was statically linked to the exe (or in NullPointer''s terminology "LIB/DLL"). So with DLLs you never have to recompile the executables using them.

TwistedOne, just a correction for your post, Windows also searches the directory from which the application was started (which, as you correctly stated, may be diferent than he current directory).

I also agree with the person who recomended not to put files in windows directories or change system settings like the path, but a good idea would be to create a directory, put DLLs there, then put your applicatinos in separate subdirectories inside this directory, then open the DLLs with "..\TheDLL.dll". (But as with the registry technique, you will not be able to statically link, as Windows does not search in the parent directory, that''s why I said it is good to specify a particular path for the DLLs.)

Plase correct me if I am wrong,
Topgoro

Share this post


Link to post
Share on other sites
"So with DLLs you never have to recompile the executables using them."

If the DLL is statically linked, then you will only have to recompile it IF the exports change. Try changing the parameters or the name of the exported function in your testDll, or adding new ones. You will have recompile the client exe since the DLLs .lib file would have changed.

If the DLL is loaded at runtime, then you dont ever have to recompile the client.

Share this post


Link to post
Share on other sites
Umm? Ew! DLLs should never be put in any of the windows directories. Even things like MFC.

You're quite mad, you know that? Looking in WinNT/System32, I find 10MB of readily identifiable MFC DLLs.

Given the great number of MFC based applications, that would be potentially an extra 10MB per application if they stored their MFC DLLs in the same directory. It's more than likely you'll have numerous applications, too (Visual C++, WordPad, Word, almost any C++ GUI application, regardless of author...).

Putting dlls in the windows directories, or modifying the DOS path, is against the rules (even if you're allowed to do it).

No, it's not. You are supposed to put DLLs in the %SystemRoot%/System(32) directory if they are shared by more than one application. If only one uses it, then put it either with your application, or with Windows.

If it's shared, then you are supposed to place it in a location on the path...and the system directory is a guaranteed location. Otherwise you are taking up space on an end users hard drive for no valid reason.

However, I agree in that changing the system path is a bit of a faux pas; don't do it unless you have very good reason to do so, such as a development need (Java, CORBA, Delphi, etc.). Games do not qualify as a "very good reason".

It can cause so many horrible, evil problems that to suggest doing so makes me feel ill.

No, it wont. The mere presence of a file is inconsequential. DirectX and OpenGL are in the system directory, and there aren't any problems with those (the only problems are at the driver and application levels, not the library level).

If you're concerned about the versioning aspect of shared libraries, do what MFC does, and include the versioning info in the filename itself (this is akin to COM versioning).

All in all, I suggest everyone pick up a book on getting your applications certified for Windows (i.e., logo certification). It details the requirements of all applications that are released for Windows (not a strict rule, only one that you follow if you want to put the official "Windows Compatible" logo on your product).

P.S. - Delay loading rocks! =)

-------------------
Revolver, aka Brian Smith
MIS Programmer Analyst
brian.smith@realpage.com
RealPage >> www.realpage.com

My views aren't even mine, much less my employers. =)


Edited by - revolver on 4/19/00 11:27:17 AM

Share this post


Link to post
Share on other sites
Hi all.

quote:
Original post by Skid

"So with DLLs you never have to recompile the executables using them."

If the DLL is statically linked, then you will only have to recompile it IF the exports change. Try changing the parameters or the name of the exported function in your testDll, or adding new ones. You will have recompile the client exe since the DLLs .lib file would have changed.

If the DLL is loaded at runtime, then you dont ever have to recompile the client.



Well, may be I did not express myself correctly. The person on which I was replying said "whenever the LIB changes" (and I think someone else also said "in bug fixes"). Well, when you add new functions, for instance, the LIB changes but you do not need to recompile the EXE. When you fix bugs on the DLL you also don't need to recompile the EXE.

But now what you are talking about here is *BREAKING* the EXE file compatibility whith the DLL's interface, that is something else, which will require not just EXE recompile, but it will have to be modified as well to comply with the new DLL interface.

You are right about dynamically binding the DLL functions (using LoadLibrary/GetProcAdress) only if you use a function table and the identifier to get the table address from the DLL does not change, but that would only work in the case of function name change. (Anyway, the header used to build the executable's file calling functions one name, and the header used to build the DLL's file calling it another is not good coding practice, is it? But the point is the EXE code is not broken.)

But in *ALL* cases, changing the parameters the function uses will break the EXE, requiring EXE modification and recompile, without regard to how you bind the DLL functions to the EXE.

The point is: (as long as no code is broken) EXEs will *NEVER* have to be recompiled even if the LIB or DLL used by those EXEs change.

Topgoro


Edited by - Topgoro on 4/19/00 12:42:16 PM

Share this post


Link to post
Share on other sites
Just a quick correction to my posts:

When I say "dynamically link the DLL" what I actually mean is "dynamic binding of the DLL functions" (LoadLibrary/GetProcAddress)
When I say "statically link a DLL" what I actually mean is "static binding of the DLL functions"

(I am not the only one with this mistake )

Sorry for the inconvenience.
Topgoro

Share this post


Link to post
Share on other sites
I don''t like placing the dlls in the windows or system directory because when you uninstall the program, you cannot uninstall the dlls (without some registry tracking) as some other programs might be using them. Some commercial programs I know do not uninstall their dlls, and I really hate it when they leave unused stuff in my harddrive.

I suppose I can put all the dlls in the same directory where as the executable but ideally, I would like to place them somewhere in a subdir of the program. (cause I''m creating modular libraries and their number will grow fast).

An additional 10 MB per application is not a big problem, IMO, as it doesn''t force the dlls to be backwards compatible, and it gets rid of all the versioning problems if the dlls are kept local to the application.

COM seems to be way overkill for me..

Share this post


Link to post
Share on other sites
Linking to the DLL directly is called ''load-time dynamic linking'', not ''shared library''. Loading a DLL using LoadLibrary and GetProcAddress is called ''run-time dynamic linking'', not just ''dynamic library''.

But of course, I am sure every platform uses variants on the terminology. However, the load-time/run-time dynamic linking names are the most descriptive and accurate as to the operations in question.

Tim

Share this post


Link to post
Share on other sites
quote:
You''re quite mad, you know that? Looking in WinNT/System32, I find 10MB of readily identifiable MFC DLLs.


I didn''t say they aren''t put there, just that they shouldn''t be. ''With the way it works at the moment'' is the bit I left out. Even this supposed auto-fixing stuff in win2k won''t help much.

quote:
Given the great number of MFC based applications, that would be potentially an extra 10MB per application if they stored their MFC DLLs in the same directory. It''s more than likely you''ll have numerous applications, too (Visual C++, WordPad, Word, almost any C++ GUI application, regardless of author...).


Have you never seen the problems caused by applications blindly writing over DLLs without version checking them, or problems where MS changes the DLL but keeps the version number the same, or releases a newer DLL with an older version...

Or the fact that (to move to a different MS dll) the VC6 C runtime dll wasn''t compatible with the VC5 one, and so any VC5 app that was dynamic-linked to the runtime broke the moment a VC6 compiler / compiled app installed the new runtime...

And you would not believe the problems we''ve been having with the various microsoft data access dlls here at my day job...

All of these caused by various things overwriting the dlls in the system directory.

If they could do it right, then I would accept that it''s the right thing to do. But they can''t.

Not many DLLs qualify as being that shareable, anyway. A game shouldn''t need to. If it needs to upgrade something system-wise, it should come with the redistributables that should be provided for things - like GLSetup, for instance.

quote:
It can cause so many horrible, evil problems that to suggest doing so makes me feel ill.

No, it wont. The mere presence of a file is inconsequential.


I didn''t say it were. That wasn''t the point I was making. See my points above.

quote:
If you''re concerned about the versioning aspect of shared libraries, do what MFC does, and include the versioning info in the filename itself (this is akin to COM versioning).


There are still umpteen versions of MFC42.dll, you know. It just specifies the MFC version number, not the actual build of that version of MFC.

quote:
All in all, I suggest everyone pick up a book on getting your applications certified for Windows (i.e., logo certification). It details the requirements of all applications that are released for Windows (not a strict rule, only one that you follow if you want to put the official "Windows Compatible" logo on your product).


Or just read the MSDN Library articles on the subject, should you have access to the CDs/DVD/website.

quote:
P.S. - Delay loading rocks! =)

It does, doesn''t it?


TheTwistedOne
http://www.angrycake.com

Share this post


Link to post
Share on other sites

  • Advertisement