Dynamic Link Libraries Inside-Out - Types of DLL Linking
(Page 5 of 9 )
Types of DLL Linking
Static Linking
It’s not actually with Dynamic link libraries but it’s worth explaining here so that you may see the benefits of dynamic linking. Special libraries called static libraries are used when you don’t want your final compiled application to have any dependencies. So to make it standalone, the compiler embeds all the code from the static library in the final executable and removes any dependencies it had. If you’ve used the Borland C++ compiler then you’d know because it used to put the code of all the functions that you’ve used in your program in the program code itself and you need no libraries to run the final executables. But the overhead is huge. Each executable will have its own copy of all the functions. With small libraries with a few Kilobyte of overhead, it must be fine but what about big libraries like MFC. So here comes dynamic linking to the rescue.
Dynamic Linking
Dynamic linking refers to linking at runtime rather than at compile time. Information is still embedded in the final executable but it’s the bare minimum for the loader (which loads the executable at runtime in the memory) to identify the DLL the program uses and load them with the application by mapping all the DLLs to the process’ address space. Dynamic linking has two forms depending on how the information is embedded in the final executable. They are Implicit Linking and Explicit Linking:
Implicit Linking: Implicit linking occurs at compile time when an application's code makes a reference to an exported DLL function. When the source code for the calling executable is compiled, the DLL function call translates to an external function reference in the object code. To resolve this external reference, the application must link with the import library (.LIB file) that is produced when the DLL is built.In the VC++ IDE one may specify these in the Project | Settings Dialog on the Link tab as shown below:
Figure 2: Specifying the Import Libraries
Here you can see WinScard.lib and a custom build SCardLib.lib specified as the import libraries for use at link time.
The import library only contains information about the exported symbols from the DLL and no actual code that helps the linker resolve any function calls made to the DLL. If the linker finds the function export information in a lib file ( import library), it assumes that the code for that function exists in a DLL, and to resolve references to that function the linker simply adds information to the final executable file that can be used by system loader when the process starts.
When the loader prepares a program for execution, that contains dynamically linked symbols, it uses the information embedded in the program's executable file at link time to locate the required DLLs. If it cannot locate the DLL, the system terminates the process and displays a dialog box that reports the error. Otherwise, the system loads the DLL (if not already loaded) and maps the DLL modules into the process' address space.
If any of the DLLs have an entry-point function (as discussed above), the operating system calls the function. The fdwReason parameter has the value DLL_PROCESS_ATTACH that indicates that the DLL is attaching to the process. If the entry-point function does not return TRUE, the system aborts loading the process and reports the error.
As a final step, the loader modifies the executable code of the process to point to DLL functions wherever a reference to them are made.
Like the rest of a program's code, DLL code is mapped into the address space of the process when the process starts up and it is loaded into memory only when needed.
Explicit Linking: Most of the applications that are developed use implicit linking because it is the easiest linking method to use. But due to design constraints, sometimes explicit linking is necessary. Here are some common situations when one needs to use explicit linking:
- When the application does not know the name of a DLL and/or exports that it will have to load. For example, the application might need to obtain the name of the DLL and the exported functions from a configuration file.
- A process using implicit linking is terminated by the operating system if the DLL is not found at process startup. A process using explicit linking is not terminated in this situation and can attempt to recover from the error. For example, the process could notify the user of the error and have the user specify another path to the DLL.
- A process using implicit linking is also terminated if any of the DLLs it is linked to have a DllMain function that fails. A process using explicit linking is not terminated in this situation if it handles such a condition.
- An application that implicitly links to many DLLs can be slow to start because Windows loads all of the DLLs when the application loads. To improve startup performance, an application can implicitly link to those DLLs needed immediately after loading and wait to explicitly link to the other DLLs when they are needed.
- Explicit linking eliminates the need to link the application with an import library. If changes in the DLL cause the export ordinals to change, applications using explicit linking do not have to relink (assuming they are calling GetProcAddress with a name of a function and not with an ordinal value), whereas applications using implicit linking must relink to the new import library.
Next: Resource Only DLLs >>
More Code Examples Articles
More By Digvijay Chauhan
/ 56 
