Software Library

Origin of the name

The name of library is derived from the human behavior: when one is unaware of how to do something of technique (for example, to plant seeds in a garden) and that one wants to however do it, one can go to document oneself in Bibliothèque and to consult books indicating how to proceed without having to reinvent the procedure oneself and each time.

The programs proceed a little in the same way: rather than to code a current procedure in each program by needing some (what wants to say that the same procedure would be rewritten as much once on a computer than there are programs likely to use it), one gathers these procedures in libraries. If a program has a function to fill and that this one is in library, it will use it directly.

Design and organization of the libraries

The traditional organization of the libraries passes by a cutting set of themes of the functions, making it possible to the programmer to more easily find the function which it needs. This cutting set of themes makes it possible to classify the libraries according to the services which they render:

Libraries of low level or libraries system: they provide services of interface with the Operating system, with the peripheral S, or provide generic tools:

libraries of inputs/outputs: functions of reading and writing of file S, peripherals of input/output like the keyboard, the screen, etc
management of structures of data system,

high level Libraries (also called libraries trade , they interact with those of low level): the functions which they contain are specific to a specific activity:

graphic toolboxes: together of functions allowing to manage, to animate and post complex graphic objects (for example: OpenGL),
libraries of operators of Image processing: together of functions intended to structure information in an image at ends of analysis,
management of structures of data user,

Other libraries:

combining in functional Programming,
protocols of Métaprogrammation.

The Application program interface (more commonly called by its Acronym API English for Application programming interface ) is the visible part of a library or a whole of libraries, making it possible to the programmer to choose among the functions available that which will render the service to him which it needs. APIs are presented in the form of a list of the names of the functions ou/et classes available, with a documentation on the Paramètre S to be provided them and on the turned over results.

Implementation of the libraries to the format of the operating system

Principles

So that the achievable code can reach the instructions of a function of a library which it uses, it is necessary that each call of function in the code is associated with the actual address of the first instruction of the function called in the library.

For that, there exist several methods and tools, which intervene after the stage of compilation:

the linkage editing ensures the installation, in the achievable code of the application, the instructions branch towards the external functions (resulting from one or several libraries);
if the linkage editing is dynamic, intervenes a allowing charger, during the execution of the program, to bring in memory the functions of the libraries used, so that when a function is called, its code is available in memory.
if the edition is static: the code of the functions used by the application is integrated into the implementation code which becomes by là-même autonomous.

The loading of the libraries can occur in two manners:

With stolen the at the time of a call by the program which exploits of it a function (late connection), this technique with the advantage of charging only the code really necessary,
Or with the loading of the program for its execution.

A library is in theory divided by the operating system in order not to duplicate its code in all the applications appealing there. See however the possibility of simultaneous versions.

Dynamically charged libraries

A library dynamic , named Dynamic Link Library (.dll) for Windows and named shared object (.so) or " dynamic library" under UNIX, is a file of software library used by a workable program, but by not forming part.

This file contains functions which could be called during the execution of a program, without those being included in its achievable.

The advantages of the dynamic libraries are:

the reduction of the size of achievable, since certain parts of the Logiciel are apart from him,
and the possible update of the useful functions for all the applications which use them. The applications profit then automatically from the corrections or the functional improvements of the bilibothèque

Divided libraries

When several programs use the same libraries, it is judicious to charge those only once in memory and to let all the programs use the same copy of it. One then speaks about divided libraries . A library can be dynamic without to be divided, and divided without being dynamic.

The fact of dividing libraries implies strong constraints of design so that the calls of function by a program, likely to modify the state interns library, do not disturb the other programs which also use it. In a system Multitâche, as one does not control the moments when the functions of the library are called, it is possible that a function is called several times simultaneously. One calls Réentrance the faculty of a library to being able to be used simultaneously by several applications.

Simultaneous versions

During the replacement of a version of library by another, it happens that certain programs functioning with the old version cannot function any more with the news. The problem is solved by a mechanism of version of library and compatibility between version

Specific cases in various operating systems

Windows

DLL means Dynamic Link Library , or in French Bibliothèque of dynamic bonds, within the framework of the Operating system Windows. Traditionally, the name of these files ends in the extension “.dll”. A DLL can contain code or resources which are then made available to other applications.

The code contained in a DLL is charged only once in memory. Thus, when a process tries to charge a DLL which is already in memory, the existing code is map in the memory of the program without a second loading being necessary, gaining place in RAM. When all the processes which exploited a DLL are finished, according to the type of the library and the parameters Windows, the memory capacity which was allotted to him can be released or not modified so that the next programs hosts do not have with réeffectuer the operation of loading.

A DLL can be statically or dynamically dependant on a program. In the first case, the program explicitly states to need a function contained in a library and the resolution of bonds is carried out by the data link at the time of the phase of compilation of the program. The program then includes in its binary structure the list of the libraries necessary to its good performance in its " count of the exportations" ( export counts ). The charger of programs of Windows then checks during the execution of the program that all the DLL necessary are available, and if it is not the case, the loading stops by posting a message indicating that dependences necessary to achievable could not be found. In the second case, it is the program which explicitly asks for the loading of a library during its execution using the API LoadLibrary in order to obtain a pointer on the desired function. This last approach is more painful because it requires a greater effort on behalf of the programmer, but it makes it possible on the one hand not to prevent the execution of a program related to a library whose existence on the host system is not certain, on the other hand constitutes sometimes the only means of reaching functions which are not declared in the files of interface provided by the editor and which are thus to regard as " not documentées".

Languages like C, C++ or Delphi are ready to create DLL which can be exploited by other programs. Many development tools which propose libraries of execution following the example MFC or VCL of Borland propose either a static connection (direct integration of the code in the achievable one) or a dynamic connection (the library is then to distribute in the form of DLL).

The use of DLL makes it possible to place at the disposal codes it and to make modular the architecture of an application. The update of this one can also be done by replacing only the DLL obsolete. Nevertheless, the use of several concurrent versions of DLL is problematic under Windows and led to certain incompatibilities gathered under the term DLL Hell .

The DLL are required in the current directory, then in the repertories included in the variable of environment path like c:\windows and c:\windows\system32 .

Unix, GNU/Linux and BSD

Under the systems of the type Unix, the libraries will be conventionally named using the extension .so ( shared object), .dylib (dynamic library of MacOSX), .a (, Unix files traditional), .sl (" shared library") or .sa (" shared archive" , SunOS).

The files .so are required in the repertories described by /etc/ld.so.conf (documentation available with man ldconfig).

The libraries can evolve/move and various versions can be used on the same system, for example: /usr/lib/libxml2.so (bond) /usr/lib/libxml2.so.2 (bond) /usr/lib/libxml2.so.2.6.6 /usr/lib/libxml.so.1 (bond) /usr/lib/libxml.so.1.8.17

Examples

C:\WINNT\system32\wsock32.dll /usr/lib/libxml2.so

Libraries of languages of scripts

The languages of scripts like python or Perl have their own libraries, which are often written in the known as language of script.

For example the library python2.4-pychart is composed in particular of the three following files:

/usr/lib/python2.4/site-packages/pychart/log_coord.py
/usr/lib/python2.4/site-packages/pychart/axis_doc.py
/usr/lib/python2.4/site-packages/pychart/object_set.py

Random links: