Hardware Reference
In-Depth Information
brary were statically bound to each program using it, it would appear in many ex-
ecutable binaries on the disk and in memory, wasting space. With DLLs, each li-
brary appears only once on disk and once in memory.
In addition to saving space, this approach makes it easy to update library pro-
cedures, even after the programs using them have been compiled and linked. For
commercial software packages, where the users rarely have the source code, using
DLLs means that the software vendor can fix bugs in the libraries by just distribut-
ing new DLL files over the Internet, without requiring any changes to the main
program binaries.
The main difference between a DLL and an executable binary is that a DLL
cannot be started and run on its own (because it has no main program). It also has
different information in its header. In addition, the DLL as a whole has several
extra procedures not related to the procedures in the library. For example, there is
one procedure that is automatically called whenever a new process is bound to the
DLL and another one that is automatically called whenever a process is unbound
from it. These procedures can allocate and deallocate memory or manage other re-
sources needed by the DLL.
There are two ways for a program to bind to a DLL. In the first way, called
implicit linking , the user's program is statically linked with a special file called an
import library that is generated by a utility program that extracts certain infor-
mation from the DLL. The import library provides the glue that allows the user
program to access the DLL. A user program can be linked with multiple import li-
braries. When a program using implicit linking is loaded into memory for execu-
tion, Windows examines it to see which DLLs it uses and checks to see if all of
them are already in memory. Those that are not in memory are loaded immediate-
ly (but not necessarily in their entirety, since they are paged). Some changes are
then made to the data structures in the import libraries so the called procedures can
be located, somewhat analogous to the changes shown in Fig. 7-17. They also
have to be mapped into the program's virtual address space. At this point, the user
program is ready to run and can call the procedures in the DLLs as though they had
been statically bound with it.
The alternative to implicit linking is (not surprisingly) explicit linking . This
approach does not require import libraries and does not cause the DLLs to be load-
ed at the same time the user program is. Instead, the user program makes an expli-
cit call at run time to bind to a DLL, then makes additional calls to get the ad-
dresses of procedures it needs. Once these have been found, it can call the proce-
dures. When it is all done, it makes a final call to unbind from the DLL. When the
last process unbinds from a DLL, the DLL can be removed from memory.
It is important to realize that a procedure in a DLL does not have any identity
of its own (as a thread or process does). It runs in the called's thread and uses the
called's stack for its local variables. It can have process-specific static data (as
well as shared data) and otherwise behaves the same as a statically-linked proce-
dure. The only essential difference is how the binding to it is performed.
 
Search WWH ::




Custom Search