Dynamic library
A dynamic library is a library that contains functions and data that can be used by a computer program at run-time as loaded from a file separate from the program executable. Dynamic linking or late binding allows for using a dynamic library by linking program library references with the associated objects in the library either at load-time or run-time. At program build-time, the linker records what library objects the program uses. When the program is run, a dynamic linker or linking loader associates program library references with the associated objects in the library.
A dynamic library can be linked at build-time to a stub for each library resource that is resolved at run-time. Alternatively, a dynamic library can be loaded without linking to stubs.
Most modern operating systems use the same format for both a dynamic library and an executable which affords two main advantages: it necessitates only one loader, and it allows an executable file to be used as a shared library. Examples of file formats use for both dynamic library and executable files include ELF, Mach-O, and PE.
A dynamic library is called by different names in different contexts. In Windows and OS/2 the technology is called dynamic-link library. In Unix-like user space, it's called dynamic shared object, or usually just shared object. In Linux kernel it's called loadable kernel module. In OpenVMS, it's called shareable image.
As an alternative to dynamic linking, a static library is included into the program executable so that the library is not required at run-time.
Dynamic loading
Dynamic loading is the process of loading a dynamic library at run-time and also unloading a library. A load can be initiated implicitly or explicitly by a program. An implicit request occurs if the program is configured to automatically load the dynamic library and this is setup at link-time. Explicit requests are made by a program via operating system API calls. For instance, Windows providesLoadLibrary, LoadLibraryEx, FreeLibrary and GetProcAddress. POSIX-based systems, including most UNIX and UNIX-like systems, use dlopen, dlclose and dlsym.A dynamic loader locates a dynamic library on request and implementation varies. Some loaders depend on the executable storing a full path to the library. Any change to the library name or location results in a run-time failure. More commonly, the library name without path information is stored in the executable, and the loader applies a search algorithm to find the file.
If a dynamic library that an program depends is unavailable or replaced with an incompatible version, the executable will fail at run-time. This is called dependency hell and on Windows DLL hell. Issues can be minimized by naming library files with a version number and by following versioning rules that require changing the version when an incompatible change is made.
Windows
For a custom DLL Windows checks the directory where it loaded the program; directories configured viaSetDllDirectory; the System32, System, and Windows directories; then the current working directory; and finally the directories specified by the PATH environment variable. Applications written for the .NET Framework, also check the Global Assembly Cache as the primary store of shared DLL files to remove the issue of DLL hell.Originally, for COM, Windows would only query the registry to locate a DLL that provides an object class. Later, Windows allowed for loading from a DLL file co-located with the program executable.
To address "DLL hell", Windows applications are typically installed with private DLL files and the system prevents replacement of shared system DLLs with earlier versions.