Download Dynamic Link Library
Barbra Mothershed
A dynamic link library (DLL) is a collection of small programs that larger programs can load when needed to complete specific tasks. The small program, called a DLL file, contains instructions that help the larger program handle what may not be a core function of the original program.
In addition to being a generic term for dynamic link libraries, Dynamic Link Library is also the name of Microsoft's version of the shared library concept for Windows. A shared library can exist in any operating system (OS).
The computer goes through several intermediate steps for this to occur. During those steps, multiple files are linked to one. There are two types of linking -- static and dynamic -- and two types of corresponding link libraries:
Static links. These are linked earlier in the process and are embedded into the executable. Static libraries are linked to the executable when the program is compiled. Dynamic libraries are linked later, either at runtime or at load time. Static libraries are not shared between programs because they are written into the individual executable.
Dynamic links. DLLs contain the files that a program links to. The libraries already are stored on the computer, external to the program that the user writes. They are called dynamic because they are not embedded in the executable -- they just link to it when needed.
An import library, which is a type of static library, replaces all placeholder symbols with actual links to the necessary DLL data in the main program at load time, pulling those functions from the DLL library. Programs provide the name of the library, and the OS creates a path to the link library. Different programs have their own language-specific calling conventions for linking to DLLs.
Because dynamic libraries are not written into the executable, the same shared library can be used by more than one program at the same time. They can also be modified without changing the entire program that is using it.
A dynamically linked program has a small bit of code that maps the DLL into virtual memory, where the program can access it at runtime or load time. With this setup, the dynamically linked program doesn't have to repeatedly access physical memory to access the library. Virtual memory links the same page of physical memory to different programs' virtual addresses -- also known as address space -- as different processes are run.
In the Windows operating systems, dynamic files have a ".dll" file extension, and static files have a ".lib" extension. DLL files may also have ".ocx" (ActiveX), ".cpl" (Control Panel) or ".drv" (driver) suffixes, depending on the DLL function.
Programs do not always need dynamic libraries. In some cases, static linking is preferable. However, some programs specify DLLs that are needed to run and will return an error message if they cannot be accessed.
The same architectural concept that allowed GDI to load different device drivers also allowed the Windows shell to load different Windows programs, and for these programs to invoke API calls from the shared USER and GDI libraries. That concept was "dynamic linking".
In a conventional non-shared static library, sections of code are simply added to the calling program when its executable is built at the "linking" phase; if two programs call the same routine, the routine is included in both the programs during the linking stage of the two. With dynamic linking, shared code is placed into a single, separate file. The programs that call this file are connected to it at run time, with the operating system (or, in the case of early versions of Windows, the OS-extension), performing the binding.
This notion of building up the operating system from a collection of dynamically loaded libraries is a core concept of Windows that persists as of 2015[update].DLLs provide the standard benefits of shared libraries, such as modularity. Modularity allows changes to be made to code and data in a single self-contained DLL shared by several applications without any change to the applications themselves.
Another benefit of modularity is the use of generic interfaces for plug-ins. A single interface may be developed which allows old as well as new modules to be integrated seamlessly at run-time into pre-existing applications, without any modification to the application itself. This concept of dynamic extensibility is taken to the extreme with the Component Object Model, the underpinnings of ActiveX.
In Windows 1.x, 2.x and 3.x, all Windows applications shared the same address space as well as the same memory. A DLL was only loaded once into this address space; from then on, all programs using the library accessed it. The library's data was shared across all the programs. This could be used as an indirect form of inter-process communication, or it could accidentally corrupt the different programs. With the introduction of 32-bit libraries in Windows 95, every process ran in its own address space. While the DLL code may be shared, the data is private except where shared data is explicitly requested by the library. That said, large swathes of Windows 95, Windows 98 and Windows Me were built from 16-bit libraries, which limited the performance of the Pentium Pro microprocessor when launched, and ultimately limited the stability and scalability of the DOS-based versions of Windows.
DLLs provide a mechanism for shared code and data, allowing a developer of shared code/data to upgrade functionality without requiring applications to be re-linked or re-compiled. From the application development point of view, Windows and OS/2 can be thought of as a collection of DLLs that are upgraded, allowing applications for one version of the OS to work in a later one, provided that the OS vendor has ensured that the interfaces and functionality are compatible.
Like static libraries, import libraries for DLLs are noted by the .lib file extension. For example, kernel32.dll, the primary dynamic library for Windows's base functions such as file creation and memory management, is linked via kernel32.lib. The usual way to tell an import library from a proper static library is by size: the import library is much smaller as it only contains symbols referring to the actual DLL, to be processed at link-time. Both nevertheless are Unix ar format files.
Linking to dynamic libraries is usually handled by linking to an import library when building or linking to create an executable file. The created executable then contains an import address table (IAT) by which all DLL function calls are referenced (each referenced DLL function contains its own entry in the IAT). At run-time, the IAT is filled with appropriate addresses that point directly to a function in the separately loaded DLL.[3]
In Cygwin/MSYS and MinGW, import libraries are conventionally given the suffix .dll.a, combining both the Windows DLL suffix and the Unix ar suffix. The file format is similar, but the symbols used to mark the imports are different (_head_foo_dll vs __IMPORT_DESCRIPTOR_foo).[4] Although its GNU Binutils toolchain can generate import libraries and link to them, it is faster to link to the DLL directly.[5] An experimental tool in MinGW called genlib can be used to generate import libs with MSVC-style symbols.
It is also possible to bind an executable to a specific version of a 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 is 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. This keeps the libraries "bound" until the next OS update. It does, however, change the checksum of the executable, so it is not something that can be done with signed programs, or programs that are managed by a configuration management tool that uses checksums (such as MD5 checksums) to manage file versions. As more recent Windows versions have moved away from having fixed addresses for every loaded library (for security reasons), the opportunity and value of binding an executable is decreasing.
Delphi does not need LIB files to import functions from DLLs; to link to a DLL, the external keyword is used in the function declaration to signal the DLL name, followed by name to name the symbol (if different) or index to identify the index.
When creating DLLs in VB, the IDE will only allow creation of ActiveX DLLs, however methods have been created[7] to allow the user to explicitly tell the linker to include a .DEF file which defines the ordinal position and name of each exported function. This allows the user to create a standard Windows DLL using Visual Basic (Version 6 or lower) which can be referenced through a "Declare" statement.
Microsoft Visual C++ (MSVC) provides several extensions to standard C++ which allow functions to be specified as imported or exported directly in the C++ code; these have been adopted by other Windows C and C++ compilers, including Windows versions of GCC. These extensions use the attribute __declspec before a function declaration. Note that when C functions are accessed from C++, they must also be declared as extern "C" in C++ code, to inform the compiler that the C linkage should be used.[8]
Besides specifying imported or exported functions using __declspec attributes, they may be listed in IMPORT or EXPORTS section of the DEF file used by the project. The DEF file is processed by the linker, rather than the compiler, and thus it is not specific to C++.
31c5a71286