The code in GDI needed to translate drawing commands to operations on specific devices.
Although it could have been possible to provide hard-coded support for a limited set of devices (like the Color Graphics Adapter display, the HP LaserJet Printer Command Language), Microsoft chose a different approach.
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.
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.
As such, display drivers were merely DLLs with a .DRV extension that provided custom implementations of the same drawing API through a unified device driver interface (DDI), and the Drawing (GDI) and GUI (USER) APIs were merely the function calls exported by the GDI and USER, system DLLs with .EXE extension.
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].
This concept of dynamic extensibility is taken to the extreme with the Component Object Model, the underpinnings of ActiveX.
The DLL technology allows for an application to be modified without requiring consuming components to be re-compiled or re-linked.
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.
If some programs (or their combination of already-loaded DLLs) do not have those addresses free, then an additional physical copy of the DLL's code will need to be created, using a different set of relocated entry points.
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.
If a DLL is compressed by certain executable packers (e.g. UPX), all of its code sections are marked as read and write, and will be unshared.
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.
At run-time, the IAT is filled with appropriate addresses that point directly to a function in the separately loaded DLL.
[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.
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.
The GetProcAddress API function is used to look up exported symbols by name, and FreeLibrary – to unload the DLL.
If the DLL cannot be found or loaded, or the called function does not exist, the application will generate an exception, which may be caught and handled appropriately.
If the application does not handle the exception, it will be caught by the operating system, which will terminate the program with an error message.
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.
COM server DLLs are registered using regsvr32.exe, which places the DLL's location and its globally unique ID (GUID) in the registry.
The following examples show how to use language-specific bindings to import symbols for linking against a DLL at compile-time.
It provides mechanisms to locate and version those files as well as a language-independent and machine-readable description of the interface.
Hosting COM objects in a DLL is more lightweight and allows them to share resources with the client process.
This allows COM objects to implement powerful back-ends to simple GUI front ends such as Visual Basic and ASP.
[17] In August 2010 it gained worldwide publicity after ACROS Security rediscovered it and many hundreds of programs were found vulnerable.
[18] Programs that are run from unsafe locations, i.e. user-writable folders like the Downloads or the Temp directory, are almost always susceptible to this vulnerability.