“Some operating systems can only link in a library at loadtime, before the process starts executing; others may be able to wait until after the process has started to execute and link in the library just when it is actually referenced (i.e. during runtime). The latter is often called "delay loading". In either case, the library is called a dynamically linked library. This term is sometimes shortened to "dynamic link library" or DLL, but this last initialism is most common in Microsoft Windows environments where dynamic libraries use the filename extension .dll. See DLL.
Dynamically linked libraries date back to at least MTS (the Michigan Terminal System), built in the late 1960s. ("A History of MTS", Information Technology Digest, Vol. 5, No. 5)
Relocation
One wrinkle that the loader must handle is that the location in memory of the actual library data is not knowable until after the executable and all dynamically linked libraries have been loaded into memory, since the memory locations used depend on which specific DLLs have been loaded. It is not possible to store the absolute location of the data in the executable, nor even in the DLL.
It would theoretically be possible to examine the program at load time and replace all references to data in the libraries with pointers to the appropriate memory locations once all DLLs have been loaded, but this method would consume unacceptable amounts of either time or memory. Instead, most dynamic library systems link a symbol table with blank addresses into the program at compile time. All references to code or data in the library pass through this table, the import directory. At load time the table is modified with the location of the library code/data by the loader/linker.
The library itself contains a table of all the methods within it, known as entry points. Calls into the library "jump through" this table, looking up the location of the code in memory, then calling it. This introduces overhead in calling into the library, but the delay is usually so small as to be negligible.
Locating libraries at runtime
Dynamic linkers/loaders vary widely in functionality. Some depend on explicit paths to the libraries being stored in the executable. Any change to the library naming or layout of the filesystem will cause these systems to fail. More commonly, only the name of the library (and not the path) is stored in the executable, with the operating system supplying a system to find the library on-disk based on some algorithm.
Most Unix-like systems have a "search path" specifying file system directories in which to look for dynamic libraries. On some systems, the default path is specified in a configuration file; in others, it's wired into the dynamic loader. Some executable file formats can specify additional directories in which to search for libraries for a particular program. It can usually be overridden with an environment variable, although that's disabled for setuid and setgid programs, so that a user can't force such a program to run arbitrary code. Developers of libraries are encouraged to place their dynamic libraries in places in the default search path. On the downside this can make installation of new libraries problematic, and these "known" locations quickly become home to an increasing number of library files, making management more complex.
Microsoft Windows will check the registry to determine the proper place to find an ActiveX DLL, but for standard DLLs it will check the current working directory; the directory set by SetDllDirectory(); the System32, System, and Windows directories; and finally the PATH environment variable.
OpenStep used a more flexible system, collecting up a list of libraries from a number of known locations (similar to the PATH concept) when the system first starts. Moving libraries around causes no problems at all, although there is a time cost when first starting the system.
One of the largest disadvantages of dynamic linking is that the executables depend on the separately stored libraries in order to function properly. If the library is deleted, moved, or renamed, or if an incompatible version of the DLL is copied to a place that is earlier in the search, the executable could malfunction or even fail to load. On Windows this is commonly known as DLL hell.”