Dynamic-link library: Encyclopedia II - Dynamic-link library - Features

Dynamic-link library - Features

Dynamic-link library - Memory management

In Win32, the DLL files are organized into sections. Each section has its own set of attributes, such as being writable or read-only, executable (for code) or non-executable (for data), and so on.

The code sections of a DLL are usually shared among all the processes that use the DLL; that is, they occupy a single place in physical memory, and do not take up space in the page file. If the physical memory occupied by a code section is to be reclaimed, its contents are discarded, and later reloaded directly from the DLL file as necessary.

In contrast to code sections, the data sections of a DLL are usually private; that is, each process using the DLL has its own copy of all the DLL's data. Optionally, data sections can be made shared, allowing inter-process communication via this shared memory area. However, because user restrictions do not apply to the use of shared DLL memory, this creates a security hole; namely, one process can corrupt the shared data, which will likely cause all other sharing processes to behave undesirably. For example, a process running under a guest account can in this way corrupt another process running under a privileged account. This is an important reason to avoid the use of shared sections in DLLs.

When a DLL is compressed by an executable packer, such as UPX, all of its code sections are marked as read-and-write, and therewith unshared. Read-and-write code sections, much like private data sections, are private to each process and backed up by the page file. Thus, compressing DLLs increases both their memory and disk space consumption, and should be generally avoided for shared DLLs.

Dynamic-link library - Symbol resolution and binding

Each function exported by a DLL is identified by a numeric ordinal and optionally a name. Likewise, functions can be imported from a DLL either by ordinal or by name. It is common for internal functions to be exported by ordinal only. For most Windows API functions only the names are preserved across different Windows releases; the ordinals are subject to change. So, one cannot reliably import Windows API functions by their ordinals.

Importing functions by ordinal does not necessarily provide better performance than importing them by name: export tables of DLLs are ordered by name, so binary search can be used to find a function in this table by its name. On the other hand, only linear search can be used to find a function by its ordinal.

It is also possible to bind an executable to a specific version of DLL, that is, to resolve the addresses of imported functions at compile-time. For bound imports, the linker saves the timestamp and checksum of the DLL to which the import is bound. At run-time Windows checks to see if the same version of library is being used, and if so, Windows bypasses processing the imports. Otherwise, if the library is different from the one which was bound to, Windows processes the imports in a normal way.

Bound executables load somewhat faster if they are run in the same environment that they were compiled for, and exactly the same time if they are run in a different environment, so there's no drawback for binding the imports. For example, all the standard Windows applications are bound to the system DLLs of their respective Windows release. A good opportunity to bind an application's imports to its target environment is during the application's installation.

Dynamic-link library - Explicit run-time linking

DLL files may be explicitly loaded at run-time, a process referred to simply as run-time dynamic linking by Microsoft, by using the LoadLibrary (or LoadLibraryEx) API function. The GetProcAddress API function is used to lookup exported symbols by name, and FreeLibrary — to unload the DLL. These functions are analogous to dlopen, dlsym, and dlclose in the POSIX API.

Note that with implicit run-time linking, referred to simply as load-time dynamic linking by Microsoft, if the linked DLL file cannot be found, Windows will display an error message and fail to load the application. The application developer cannot handle the absence of DLL files linked implicitly by the compile-time linker. On the other hand, with explicit run-time linking, developers have the opportunity to provide a graceful fall-back facility.

The procedure for explicit run-time linking is the same in any language, since it depends on the Windows API rather than language constructs.

Adapted from the Wikipedia article "Features", under the G.N U Free Docmentation License. Please also see http://en.wikipedia.org/wiki