Page #22 (Role of the Linker and the OS Loader)

< BACK  NEXT >

[oR]

Dynamic Link Library

Fear not. Microsoft has provided a way of linking a library dynamically. Under Windows terminology, such a library is referred to as Dynamic Link Library (DLL). A DLL is an executable file that gets loaded when an application that uses the DLL gets executed.

DLLs can reduce memory and disk space requirements by sharing a single copy of common code and resources among multiple applications. When more than one application uses the same DLL, the operating system is smart enough to share the DLL s read-only executable code among all the applications.

DLLs are compiled and linked independently of the applications that use them; they can be updated without requiring applications to be recompiled or relinked.

If several applications work together as a system and they all share such common DLLs, the entire system can be improved by replacing the common DLLs with enhanced versions. A bug fix in one such DLL indirectly fixes the bug in all applications that use it. Likewise, performance enhancements or new functionality in the DLL benefit all applications that use the DLL.

In order for us to use a DLL instead of a statically linked library, we have to:

• prevent the linker from complaining about unresolved external symbols, and

• provide enough information to the loader so that it can load the appropriate DLL dynamically and resolve the symbols to their corresponding locations in memory before executing the application

Using a special type of library file called the import library can satisfy both these requirements. This binary file does not contain any code; it contains all the references to the functions and other declarations to satisfy the linker and to help the loader resolve the symbols at run time.

When the application object modules are linked with the import library, the linker now has no reason to complain about unresolved external symbols. It will create the final executable. When this executable is run, the loader examines the image for all the DLLs that need to be loaded and tries to load them. The search path used by Windows to locate a DLL can be found in Visual C++ documentation [MSDN-00]. After loading each DLL, the loader resolves all the external symbols and patches the application image with the actual procedure entry points.

The loader will complain if:

• the DLL could not be located, or

• the procedure entry point for a particular symbol could not be located in the DLL.

In either case, the execution is aborted.

To facilitate locating a symbol in a DLL, the DLL has to export all the symbols that need to be exposed. One way to do this is to list all the symbols that need to be exported in a file called the module definition file. For the VCR code, we need to export two symbols CVcr::CVcr and CVcr::GetSignalValue. Keep in mind that we need to use name-mangled versions of these symbols. Here s what the module definition file contains:

 ; File VCR.DEF  LIBRARY   VCR.DLL  EXPORTS    ?GetSignalValue@CVcr@@QAEJXZ    ??0CVcr@@QAE@XZ 

Let s compile and link the VCR code to create a DLL.

 cl  c vcr.cpp  link -dll -def:vcr.def vcr.obj 

In the above commands, option dll tells the linker to create a DLL file, and option -def tells the linker to use vcr.def module definition file (option -def). The linker generates two files of interest to us:

• The dynamic link library (vcr.dll), and

• An import library (vcr.lib) that exposes the two above-mentioned symbols.

Let s compile the TV code and link the object file with the import library to create the final application.

 cl  c tv.cpp  link tv.obj vcr.lib 

When we run this newly created application, the generated output is exactly the same as when it was a monolithic application. The only difference is that the new executable took a little longer to load, but nothing noticeable, as the loader had to resolve all the symbols during run time.

We have now broken our original executable into two components tv.exe and vcr.dll. Both the components are required to execute the application. However, we now have the ability to field-replace the DLL, thus enabling an easy mechanism to fix a bug or upgrade to an enhanced version. Mission accomplished!

All that remains is to convince ourselves that field-replacing a DLL is foolproof.

< BACK  NEXT >