L'organisation classique des bibliothèques passe par un découpage thématique des fonctions, permettant au programmeur de retrouver plus facilement la fonction dont il a besoin. Ce découpage thématique permet de classer les bibliothèques selon les services qu'elles rendent :
L'interface de programmation (plus communément appelée par son acronyme anglais API pour Application Programming Interface) est la partie visible d'une bibliothèque ou d'un ensemble de bibliothèques, permettant au programmeur de choisir parmi les fonctions disponibles celle qui va lui rendre le service dont il a besoin. Les API se présentent comme une liste des noms des fonctions ou/et classes disponibles, avec une documentation sur les paramètres à leur fournir et sur les résultats retournés.
Les langages de scripts comme python ou perl ont leurs propres bibliothèques, qui sont souvent écrites dans le langage dit "de script".
Par exemple la bibliothèque python2.4-pychart se compose notamment des trois fichiers suivants :
DLL signifie Dynamic Link Library, ou en français Bibliothèque de liens dynamiques, dans le cadre du Système d'exploitation Windows, et compatibles (Wine, ReactOS, Darwine). Traditionnellement, le nom de ces fichiers se termine par l'extension « .dll ». Une DLL peut contenir du code ou des ressources qui sont alors rendus disponibles à d'autres applications.
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire. Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en mémoire, le code existant est mappé dans la mémoire du programme sans qu'un second chargement soit nécessaire, gagnant de la place en RAM. Lorsque tous les processus qui exploitaient une DLL se sont terminés, suivant le type de la bibliothèque et les paramètres Windows, l'espace mémoire qui lui était attribué peut être libéré ou non modifié afin que les prochains programmes hôtes n'aient pas à réeffectuer l'opération de chargement.
Une DLL peut être liée statiquement ou dynamiquement à un programme. Dans le premier cas, le programme déclare explicitement avoir besoin d'une fonction contenue dans une bibliothèque et la résolution de liens est effectuée par l'éditeur de lien au moment de la phase de compilation du programme. Le programme inclut alors dans sa structure binaire la liste des bibliothèques nécessaires à son bon fonctionnement dans sa "table des exportations" (export table). Le chargeur de programmes de Windows vérifie alors lors de l'exécution du programme que toutes les DLL requises sont disponibles, et si ce n'est pas le cas, stoppe le chargement en affichant un message indiquant que des dépendances nécessaires à l'exécutable n'ont pu être trouvées. Dans le second cas, c'est le programme qui demande explicitement le chargement d'une bibliothèque durant son exécution à l'aide de l'API LoadLibrary afin d'obtenir un pointeur sur la fonction désirée. Cette dernière approche est plus pénible car elle nécessite un effort plus important de la part du programmeur, mais elle permet d'une part de ne pas empêcher l'exécution d'un programme lié à une bibliothèque dont l'existence sur le système hôte n'est pas certaine, d'autre part constitue parfois le seul moyen d'accéder à des fonctions qui ne sont pas déclarées dans les fichiers d'interface fournis par l'éditeur et qui sont donc à considérer comme "non documentées".[c]
Des langages comme C, C++ ou Delphi sont aptes à créer des DLL qui peuvent être exploitées par d'autres programmes. De nombreux outils de développement qui proposent des bibliothèques d'exécution à l'instar des MFC ou de la VCL de Borland proposent soit une liaison statique (intégration directe du code dans l'exécutable) soit une liaison dynamique (la bibliothèque est alors à distribuer sous forme de DLL).
L'utilisation de DLL permet de mettre à disposition du code et de rendre modulaire l'architecture d'une application. La mise à jour de celle-ci peut également se faire en remplaçant uniquement les DLL obsolètes. Néanmoins, l'utilisation de plusieurs versions concurrentes de DLL est problématique sous Windows et conduit à certaines incompatibilités regroupées sous le terme DLL Hell.
Les DLL sont recherchées dans le répertoire courant, puis dans les répertoires inclus dans la variable d'environnement path comme c:\windows et c:\windows\system32.
Sous les systèmes de type Unix, les bibliothèques seront conventionnellement nommées à l'aide de l'extension .so
(shared object), .dylib
(dynamic library de MacOSX), .a
(archive, Unix traditionnels), .sl
("shared library") ou encore .sa
("shared archive", SunOS).
Les fichiers .so sont recherchés dans les répertoires décrits par /etc/ld.so.conf (documentation disponible avec man ldconfig).
Les bibliothèques peuvent évoluer et différentes versions peuvent être utilisées sur le même système, par exemple:
/usr/lib/libxml2.so (lien) /usr/lib/libxml2.so.2 (lien) /usr/lib/libxml2.so.2.6.6 /usr/lib/libxml.so.1 (lien) /usr/lib/libxml.so.1.8.17
C:\WINNT\system32\wsock32.dll /usr/lib/libxml2.so