Re: Dynamic DLL Loading or Static ?
From: Peter Below (TeamB) (100113.1101_at_compuXXserve.com)
Date: Sat, 15 Nov 2003 16:17:22 +0100
In article <email@example.com>, Andrew Jameson wrote:
> It's strange the number of times you suddenly realise you don't know why you
> do something ... you've always done it that way is the usual answer.
> Loading DLL's ... can someone just give me a good reason for dynamically
> loading them ? (I usually do but I'm not sure why I do !).
a) the DLL contains functionality that is rarely needed by the application.
Loading it on demand the cuts down on load time for the app and on memory foot
b) the DLL contains functionality that depends on specific platform features.
If you load it dynamically you can check the platform the program is running
on before loading the DLL and react accordingly if the platform does not
support the needed functionality.
c) the DLL contains functionality that tends to change in its implementation
details (but not the interface the DLL exports) faster than the host EXE. You
want to provide a means for your host app to download an updated version of
the DLL from somewhere. The host app could not replace a DLL you have already
d) you have partitioned your apps functionality into modules the user can buy
separately. The host app only loads modules it finds in a specific location,
All of this applies also to packages, of course.
> To be very much more specific ... I'm using BASS.dll (a 3D Audio DLL). I'm
> experiencing a very, very rare crash on XP systems when I initialize this
> DLL and I'm loading it dynamically. I was wondering whether it might be more
> stable if used static loading.
You will just get the crash when starting the application if you load the DLL
There are two areas where static and dynamic loading differ.
a) Initialization sequence.
If you use static loading the DLL will be loaded and its Initialization
sections will execute before the host apps Initialization sections are
executed. For dynamic loading the sequence is reversed, obviously.
b) Path control
If you use static loading you leave the task of finding the DLL to the OS.
You cannot define a full path, so the OS uses a specific search sequence
(documented for LoadLibrary in the platform SDK) and it may end up finding
a different version of the DLL elsewhere. If you use dynamic loading you
have the option of specifying a full pathname for LoadLibrary, so you
control which DLL version gets loaded if there are several around.
> Now the other area that I'm not clear on ... a user has Bass.dll (version
> 1.8) in their System folder and I'm relying on Bass.dll(version 2.0) which
> is in my exe folder. With dynamic loading, I'm making a specific reference
> to the file ... what happens in the static load when the user's got 1.8
> loaded ? ( I guess maybe I'm answering my own question ?).
Check the platform SDK docs for LoadLibrary. Note that there is an additional
complication for DLLs that are loaded by the OS itself into your process,
without the process explicitely requiring them. Depending on platform even a
call to LoadLibrary may then return the module handle of an already loaded
version of the DLL, even if you explicitely requested another version via full
path. Windows versions prior to Win2K only used the file name to identify
modules, without the path.
-- Peter Below (TeamB) Use the newsgroup archives : http://www.mers.com/searchsite.html http://www.tamaracka.com/search.htm http://groups.google.com http://www.prolix.be