- Great Painters
- Accounting
- Fundamentals of Law
- Marketing
- Shorthand
- Concept Cars
- Videogames
- The World of Sports

- Blogs
- Free Software
- Google
- My Computer

- PHP Language and Applications
- Wikipedia
- Windows Vista

- Education
- Masterpieces of English Literature
- American English

- English Dictionaries
- The English Language

- Medical Emergencies
- The Theory of Memory
- The Beatles
- Dances
- Microphones
- Musical Notation
- Music Instruments
- Batteries
- Nanotechnology
- Cosmetics
- Diets
- Vegetarianism and Veganism
- Christmas Traditions
- Animals

- Fruits And Vegetables


  1. Adobe Reader
  2. Adware
  3. Altavista
  4. AOL
  5. Apple Macintosh
  6. Application software
  7. Arrow key
  8. Artificial Intelligence
  9. ASCII
  10. Assembly language
  11. Automatic translation
  12. Avatar
  13. Babylon
  14. Bandwidth
  15. Bit
  16. BitTorrent
  17. Black hat
  18. Blog
  19. Bluetooth
  20. Bulletin board system
  21. Byte
  22. Cache memory
  23. Celeron
  24. Central processing unit
  25. Chat room
  26. Client
  27. Command line interface
  28. Compiler
  29. Computer
  30. Computer bus
  31. Computer card
  32. Computer display
  33. Computer file
  34. Computer games
  35. Computer graphics
  36. Computer hardware
  37. Computer keyboard
  38. Computer networking
  39. Computer printer
  40. Computer program
  41. Computer programmer
  42. Computer science
  43. Computer security
  44. Computer software
  45. Computer storage
  46. Computer system
  47. Computer terminal
  48. Computer virus
  49. Computing
  50. Conference call
  51. Context menu
  52. Creative commons
  53. Creative Commons License
  54. Creative Technology
  55. Cursor
  56. Data
  57. Database
  58. Data storage device
  59. Debuggers
  60. Demo
  61. Desktop computer
  62. Digital divide
  63. Discussion groups
  64. DNS server
  65. Domain name
  66. DOS
  67. Download
  68. Download manager
  69. DVD-ROM
  70. DVD-RW
  71. E-mail
  72. E-mail spam
  73. File Transfer Protocol
  74. Firewall
  75. Firmware
  76. Flash memory
  77. Floppy disk drive
  78. GNU
  79. GNU General Public License
  80. GNU Project
  81. Google
  82. Google AdWords
  83. Google bomb
  84. Graphics
  85. Graphics card
  86. Hacker
  87. Hacker culture
  88. Hard disk
  89. High-level programming language
  90. Home computer
  91. HTML
  92. Hyperlink
  93. IBM
  94. Image processing
  95. Image scanner
  96. Instant messaging
  97. Instruction
  98. Intel
  99. Intel Core 2
  100. Interface
  101. Internet
  102. Internet bot
  103. Internet Explorer
  104. Internet protocols
  105. Internet service provider
  106. Interoperability
  107. IP addresses
  108. IPod
  109. Joystick
  110. JPEG
  111. Keyword
  112. Laptop computer
  113. Linux
  114. Linux kernel
  115. Liquid crystal display
  116. List of file formats
  117. List of Google products
  118. Local area network
  119. Logitech
  120. Machine language
  121. Mac OS X
  122. Macromedia Flash
  123. Mainframe computer
  124. Malware
  125. Media center
  126. Media player
  127. Megabyte
  128. Microsoft
  129. Microsoft Windows
  130. Microsoft Word
  131. Mirror site
  132. Modem
  133. Motherboard
  134. Mouse
  135. Mouse pad
  136. Mozilla Firefox
  137. Mp3
  138. MPEG
  139. MPEG-4
  140. Multimedia
  141. Musical Instrument Digital Interface
  142. Netscape
  143. Network card
  144. News ticker
  145. Office suite
  146. Online auction
  147. Online chat
  148. Open Directory Project
  149. Open source
  150. Open source software
  151. Opera
  152. Operating system
  153. Optical character recognition
  154. Optical disc
  155. output
  156. PageRank
  157. Password
  158. Pay-per-click
  159. PC speaker
  160. Peer-to-peer
  161. Pentium
  162. Peripheral
  163. Personal computer
  164. Personal digital assistant
  165. Phishing
  166. Pirated software
  167. Podcasting
  168. Pointing device
  169. POP3
  170. Programming language
  171. QuickTime
  172. Random access memory
  173. Routers
  174. Safari
  175. Scalability
  176. Scrollbar
  177. Scrolling
  178. Scroll wheel
  179. Search engine
  180. Security cracking
  181. Server
  182. Simple Mail Transfer Protocol
  183. Skype
  184. Social software
  185. Software bug
  186. Software cracker
  187. Software library
  188. Software utility
  189. Solaris Operating Environment
  190. Sound Blaster
  191. Soundcard
  192. Spam
  193. Spamdexing
  194. Spam in blogs
  195. Speech recognition
  196. Spoofing attack
  197. Spreadsheet
  198. Spyware
  199. Streaming media
  200. Supercomputer
  201. Tablet computer
  202. Telecommunications
  203. Text messaging
  204. Trackball
  205. Trojan horse
  206. TV card
  207. Unicode
  208. Uniform Resource Identifier
  209. Unix
  210. URL redirection
  211. USB flash drive
  212. USB port
  213. User interface
  214. Vlog
  215. Voice over IP
  216. Warez
  217. Wearable computer
  218. Web application
  219. Web banner
  220. Web browser
  221. Web crawler
  222. Web directories
  223. Web indexing
  224. Webmail
  225. Web page
  226. Website
  227. Wiki
  228. Wikipedia
  229. WIMP
  230. Windows CE
  231. Windows key
  232. Windows Media Player
  233. Windows Vista
  234. Word processor
  235. World Wide Web
  236. Worm
  237. XML
  238. X Window System
  239. Yahoo
  240. Zombie computer

This article is from:

All text is available under the terms of the GNU Free Documentation License: 

Library (computing)

From Wikipedia, the free encyclopedia

(Redirected from Software library)
Illustration of an application which may use to play an Ogg Vorbis file.
Illustration of an application which may use to play an Ogg Vorbis file.

In computer science, a library is a collection of subprograms used to develop software. Libraries contain "helper" code and data, which provide services to independent programs. This allows code and data to be shared and changed in a modular fashion. Some executables are both standalone programs and libraries, but most libraries are not executables. Executables and libraries make references known as links to each other through the process known as linking, which is typically done by a linker.

Most modern operating systems (OS) provide libraries that implement the majority of system services. Such libraries have commoditized the services a modern application expects an OS to provide. As such, most code used by modern applications is provided in these libraries.


Traditional libraries

Historically, libraries could only be static. A static library, also known as an archive, consists of a set of routines which are copied into a target application by the compiler, linker, or binder, producing a standalone executable application. Compiler manufacturers provide standard libraries (e.g., the C standard library), but programmers can also create their own libraries for their own use or distribution.

A linker may work on specific types of object files, and thus require specific (compatible) types of libraries. Collecting object files into a static library may ease their distribution and use. A client, either the main program or a library subroutine, accesses a library item referencing just its name. The linking process resolves references searching the libraries in the order given. Usually, it is not considered an error if a name can be found multiple times in the given set of libraries.

Dynamic linking

Dynamic linking means that the data in a library is not copied into a new executable or library at compile time, but remains in a separate file on disk. Only a minimal amount of work is done at compile time by the linker—it only records what libraries the executable needs and the index names or numbers. The majority of the work of linking is done at the time the application is loaded (loadtime) or during the execution of the process (runtime). The necessary linking code, called a loader, is actually part of the underlying operating system. At the appropriate time the loader finds the relevant libraries on disk and adds the relevant data from the libraries to the process's memory space.

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, such a library is called a dynamically linked library.

The nature of dynamic linking makes it a common boundary in software licenses.

Plugins are one common usage of dynamically linked libraries, which is especially useful when the libraries can be replaced by other libraries with a similar interface, but different functionality. Software may be said to have a "plugin architecture" if it uses libraries for core functionality with the intention that they can be replaced. Note, however, that the use of dynamically linked libraries in an application's architecture does not necessarily mean that they may be replaced.

Dynamic linking was originally developed in the Multics operating system, starting in 1964. It was also a feature of MTS (the Michigan Terminal System), built in the late 1960s.[1] In Microsoft Windows, dynamically-linked libraries are called dynamic-link libraries or "DLLs".


One wrinkle that the loader must handle is that the location in memory of the actual library data cannot be known until after the executable and all dynamically linked libraries have been loaded into memory. This is because the memory locations used depend on which specific dynamic libraries have been loaded. It is not possible to store the absolute location of the data in the executable, nor even in the library, since conflicts between different libraries would result: if two of them specified the same or overlapping addresses, it would be impossible to use both in the same program. This might change with increased adoption of 64-bit architectures, which offer enough virtual memory addresses to give every library ever written its own unique address range.

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 libraries 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. This process is still slow enough to significantly affect the speed of programs that call other programs at a very high rate, such as certain shell scripts.

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.

Unix-like systems 
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 is hard coded into the dynamic loader. Some executable file formats can specify additional directories in which to search for libraries for a particular program. This can usually be overridden with an environment variable, although it is 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 
Microsoft Windows will check the registry to determine the proper place to find an ActiveX DLL, but for other DLLs it will check the directory that the program was loaded from; the current working directory (only on older versions of Windows); any directories set by calling the SetDllDirectory() function; the System32, System, and Windows directories; and finally the directories specified by the PATH environment variable.[2]
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 biggest 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; damaging vital library files used by almost any executable in the system (such as the C library on Unix systems) will usually render the system completely unusable. On Windows this is commonly known as DLL hell.

Dynamic loading

Dynamic loading is a subset of dynamic linking where a dynamically linked library loads and unloads at run-time on request. The request to load such a dynamically linked library may be made implicity at compile-time, or explicitly by the application at run-time. Implicit requests are made by adding library references, which may include file paths or simply file names, to an object file at compile-time by a linker. Explicit requests are made by applications using a run-time linker API.

Most operating systems that support dynamically linked libraries also support dynamically loading such libraries via a run-time linker 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. Some development systems automate this process.

Remote libraries

Another solution to the library issue is to use completely separate executables (often in some lightweight form) and call them using a remote procedure call (RPC). This approach maximizes operating system re-use: the code needed to support the library is the same code being used to provide application support and security for every other program. Additionally, such systems do not require the library to exist on the same machine, but can forward the requests over the network.

The downside to such an approach is that every library call requires a considerable amount of overhead. RPC calls are generally very expensive, and often avoided where possible. Nevertheless this approach has become popular in a number of domain-specific areas, notably client-server systems and application servers such as Enterprise JavaBeans.

Shared library

In addition to being loaded statically or dynamically, libraries are also often classified according to how they are shared among programs. Dynamic libraries almost always offer some form of sharing, allowing the same library to be used by multiple programs at the same time. Static libraries, by definition, cannot be shared; they are linked into each program.

The shared library term is slightly ambiguous, because it covers at least two different concepts. First, it is the sharing of code located on disk by unrelated programs. The second concept is the sharing of code in memory, when programs execute the same physical page of RAM, mapped into different address spaces. It would seem that the latter would be preferable, and indeed it has a number of advantages. For instance on the OpenStep system, applications were often only a few hundred kilobytes in size and loaded almost instantly; the vast majority of their code was located in libraries that had already been loaded for other purposes by the operating system. There is a cost, however; shared code must be specifically written to run in a multitasking environment, and this has effects on performance.

RAM sharing can be accomplished by using position independent code as in Unix, which leads to a complex but flexible architecture, or by using normal, ie. not position independent code as in Windows and OS/2. These systems make sure, by various tricks like pre-mapping the address space and reserving slots for each DLL, that code has a great probability of being shared. Windows DLLs are not shared libraries in the Unix sense. The rest of this article concentrates on aspects common to both variants.

In most modern operating systems, shared libraries can be of the same format as the "regular" executables. This allows two main advantages: first, it requires making only one loader for both of them, rather than two. The added complexity of the one loader is considered well worth the cost. Secondly, it allows the executables also to be used as DLLs, if they have a symbol table. Typical executable/DLL formats are ELF and Mach-O (Unix) and PE (Windows). In Windows, the concept was taken one step further, with even system resources such as fonts being bundled in the DLL file format. The same is true under OpenStep, where the universal "bundle" format is used for almost all system resources.

The term DLL is mostly used on Windows and OS/2 products. On Unix platforms, the term shared library or shared object is more commonly used; consequently, the most common filename extension for shared library files is .so, usually followed by another dot and a version number. This is technically justified in view of the different semantics. More explanations are available in the position independent code article.

In some cases, an operating system can become overloaded with different versions of DLLs, which impedes its performance and stability. Such a scenario is known as DLL hell.

Object Libraries

Although dynamic linking was originally developed in the 1960s, it did not reach consumer operating systems until the late 1980s; it was generally available in some form in most operating systems by the early 1990s. It was during this same period that object-oriented programming (OOP) was becoming a significant part of the programming landscape. OOP with runtime binding requires additional information that traditional libraries don't supply; in addition to the names and entry points of the code located within, they also require a list of the objects on which they depend. This is a side-effect of one of OOP's main advantages, inheritance, which means that the complete definition of any method may be defined in a number of places. This is more than simply listing that one library requires the services of another, in a true OOP system, the libraries themselves may not be known at compile time, and vary from system to system.

At the same time another common area for development was the idea of multi-tier programs, in which a "display" running on a desktop computer would use the services of a mainframe or minicomputer for data storage or processing. For instance, a program on a GUI-based computer would send messages to a minicomputer to return small samples of a huge dataset for display. Remote procedure calls already handled these tasks, but there was no standard RPC system.

It was not long before the majority of the minicomputer and mainframe vendors were working on projects to combine the two, producing an OOP library format that could be used anywhere. Such systems were known as object libraries, or distributed objects if they supported remote access (not all did). Microsoft's COM is an example of such a system for local use, DCOM a modified version that support remote access.

For some time object libraries were the "next big thing" in the programming world. There were a number of efforts to create systems that would run across platforms, and companies competed to try to get developers locked into their own system. Examples include IBM's System Object Model (SOM/DSOM), Sun Microsystems' Distributed Objects Everywhere (DOE), NeXT's Portable Distributed Objects (PDO), Digital's ObjectBroker, Microsoft's Component Object Model (COM/DCOM), and any number of CORBA-based systems.

In the end, it turned out that OOP libraries were not the next big thing. With the exception of Microsoft's COM and NeXT's (now Apple Computer) PDO, all of these efforts have since ended.

The JAR file format is mainly used for object libraries in the Java programming language. It consists of (compressed) classes in bytecode format and is loaded by a java virtual machine or special class loaders.


GNU/Linux, Solaris and other System V Release 4 derivatives, and BSD variants
libfoo.a and files are placed in directories like /lib, /usr/lib or /usr/local/lib. The filenames always start with lib, and end with .a (archive, static library) or .so (shared object, dynamically linked library), with an optional interface number. For example is the second major interface revision of the dynamically linked library libfoo. Old Unix versions would use major and minor library revision numbers ( while contemporary Unixes will only use major revision numbers ( Dynamically loaded libraries are placed in /usr/libexec and similar directories. The .la files sometimes found in the library directories are libtool archives, not useable by the system as such.
Mac OS X and upwards
The system inherits static library conventions from BSD, with the library being in a .a file, and can use .so-style dynamically-linked libraries (with the .dylib suffix instead). Most libraries in Mac OS X, however, are "frameworks", placed inside of special directories called "bundles", which wrap the library's required files and metadata. For example a library called "My Neat Library" would be implemented in a bundle called "My Neat Library.framework".
Microsoft Windows
*.DLL files are dynamically linkable libraries. Other file name patterns may be used for specific purpose DLLs, e.g. *.OCX for OCX control libraries. The interface revisions are either encoded in the files, or abstracted away using COM-object interfaces. Depending on how they are compiled, *.LIB files can be either static libraries or representations of dynamically linkable libraries needed only during compilation. Unlike in the UNIX world where file extensions are used, when linking against .LIB file in Windows one must first know if it is static or dynamic. If dynamic linking is used a .DLL file must be present at runtime.

See also

  • Code reuse
  • Dynamic Library
  • Linker
  • Loader (computing)
  • Microsoft Dynamic Link Library
  • Object File
  • Plugin
  • Prebinding
  • Static Library


  1. ^ "A History of MTS". Information Technology Digest 5 (5).
  2. ^ Dynamic-Link Library Search Order. Microsoft Developer Network Library. Microsoft (2006-10-23). Retrieved on 2006-12-24.

External links

  • Program Library HOWTO for Linux
  • Shared Libraries - 'Linkers and Loaders' by John R. Levine
  • Dynamic Linking and Loading - 'Linkers and Loaders' by John R. Levine
  • Article Faster C++ program startups by improving runtime linking efficiency by Léon Bottou and John Ryland
  • How to Create Program Libraries by Baris Simsek
  • LIB BFD - the Binary File Descriptor Library
  • 1st Library-Centric Software Design Workshop LCSD'05 at OOPSLA'05
  • 2nd Library-Centric Software Design Workshop LCSD'06 at OOPSLA'06
  • How to create shared library(with much background info)
Retrieved from ""