Library code may be shared in memory by multiple
processes and on disk. If virtual memory is used, processes would execute the same physical page of RAM mapped into the processes' different address spaces. This has advantages. For instance, on the
OpenStep system, applications were often only a few hundred kilobytes in size and loaded quickly; most of their code was located in libraries already loaded for other purposes by the operating system. 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. These systems ensure that code has a high probability of being shared by various means, like pre-mapping the address space and reserving slots for each shared library. A third alternative is a
single-level store with a
single address space, as used by the
IBM System/38 and its successors. This allows position-dependent code, with programs and libraries assigned a permanent address in that address space. In some cases, different versions of shared libraries can cause problems, especially when libraries of different versions have the same file name and various applications are installed on a system, each requiring a specific version. This scenario is known as
DLL hell, named after the Windows and OS/2
DLL files. Most modern operating systems after 2001 have clean-up methods to eliminate such situations or use application-specific "private" libraries. == Examples ==