Many modern operating systems now use a unified format for their shared libraries and executable files.
[citation needed] In some older environments such as 16-bit Windows or MPE for the HP 3000, significant restrictions were placed on shared library code, such as only allowing stack-based (local) data.
[citation needed] Library code may be shared in memory by multiple processes, and on disk.
[citation needed] Programs can accomplish RAM sharing by using position-independent code, as in Unix, which leads to a complex but flexible architecture, or by using common virtual addresses, as in Windows and OS/2.
A third alternative is single-level store with a single address space, as used by the IBM System/38 and its successors.
Most modern operating systems after 2001 have clean-up methods to eliminate such situations or use application-specific "private" libraries.
The "DLL hell" problems with earlier Windows versions arose from using only the names of libraries, which were not guaranteed to be unique, to resolve dynamic links in programs.
(To avoid "DLL hell", later versions of Windows rely largely on options for programs to install private DLLs—essentially a partial retreat from the use of shared libraries—along with mechanisms to prevent replacement of shared system DLLs with earlier versions of them.)
Moving libraries around causes no problems at all, although users incur a time cost when first starting the system.
Some executable file formats can specify additional directories in which to search for libraries for a particular program.
[citation needed] Explicit requests are made when applications make direct calls to an operating system's API.
For instance, Microsoft Windows uses the API functions LoadLibrary, LoadLibraryEx, FreeLibrary and GetProcAddress with Microsoft Dynamic Link Libraries; POSIX-based systems, including most UNIX and UNIX-like systems, use dlopen, dlclose and dlsym.