DLL : Dynamic Link Library - ressources communes (fonctionnalités standard) enregistrées dans WinSxS et à disposition de nombreuses applications.

cr  10.01.2013      r+  03.02.2024      r-  20.04.2024      Pierre Pinard.         (Alertes et avis de sécurité au jour le jour)

Que sont les ressources communes trouvées dans WinSxS, en particulier les « DLLs » (les « DLLs » ne sont pas les seules ressources communes (partagées) présentes dans WinSxS) ?

Les « DLLs » (Dynamic Link Library) (bibliothèque de liaisons dynamiques) sont des fonctionnalités standards se traduisant par des composants (bouts de programmes standards), exécutant une fonction spécifique courante que l'on va retrouver dans de nombreuses applications. La notion de composants logiciels (une brique logiciel) liés à une architecture logiciel de plus haut niveau (une application) existe depuis toujours, sous divers noms. C'est le concept du DRY ("Don’t Repeat Yourself" - "Ne vous répétez pas").

Les DLLs sont fournies par les éditeurs de logiciels, Microsoft bien entendu, et les grands éditeurs produisant de nombreuses applications (Adobe etc.).

1. Premier avantage des DLLs :
   Lorsqu'un développeur écrit une application, il a intérêt à utiliser des briques de code (exemple : les « DLLs ») toutes faites pour accélérer son développement.

2. Second avantage des DLLs :
   Le programmeur est censé s'appuyer sur du code normalement déjà bien stable (débugué).

3. Troisième avantage des DLLs :
   Le « poids » d'une application développée en utilisant des DLLs est plus petit. De nombreuses fonctions ne sont représentées que par un appel à une fonctionnalité standard, externe au programme, qui sera mise à disposition du programme (« montée en mémoire ») par un mécanisme du système d'exploitation (techniquement, c'est une phase de post compilation (traduction du code écrit par le programmeur en un code exécutable par un ordinateur), appelée « Édition des liens » (Link Edit), qui introduit, dans le code de l'application, les appels aux bibliothèques externes).

4. Quatrième avantage des DLLs :
   Le mécanisme du système d'exploitation vérifie si la ressource (la DLL) est déjà montée en mémoire, appelée par une autre application et, si ce n'est pas le cas, il la fait monter en mémoire et donne l'adresse RAM du point d'entrée de la ressource à l'application qui l'appelle. Ainsi, on comprend qu'une ressource disponible sous forme de DLL ne monte qu'une fois en RAM et est mise à disposition de plusieurs applications.

5. Cinquième avantage des DLLs :
   Elles favorisent une technique de développement architectural des applications dites « modulaire », ce qui est, intellectuellement et pratiquement, très satisfaisant.

Donc, les DLLs, c'est génial... Cela ne présente que des avantages (lire : DRY ("Don’t Repeat Yourself" - "Ne vous répétez pas")) !

On peut voir quelles sont les DLLs utilisées par une application (et autres composants externes), et, éventuellement, rechercher quelles sont les DLLs et autres dépendances manquantes, avec Dependency Walker.

Les notions de « composants liés à l'architecture d'un programme principal », au moment de sa « post compilation » (phase dite d' « édition des liens »), existe depuis la nuit des temps informatiques.

J'utilisais des éditeurs de liens sur IBM 360 au tout début des années 1970. La dixième édition de ce document d'IBM sur l'édition des liens sous l'OS des IBM 360 remonte à 1972 !

Dans Windows, la notion de composants remonte au tout début de Windows, dès sa version 1.0, en 1985. L'enfer des DLLs conduira Microsoft à réagir avec un magasin de composants contenant toutes les formes de composants utilisées, dont les DLLs. Ce magasin prend le nom de WinSxS, à partir de Windows Vista.

Ce magasin sera protégé, ne pouvant être manipulé que par des applications éligibles au compte utilisateur spécial « TrustedInstaller » et à travers une procédure particulière.

Le concept fondateur des DLL et des Frameworks (par exemple les « Microsoft .Net Framework ») est le principe, en programmation informatique, du DRY (« Don’t Repeat Yourself » - « Ne vous répétez pas »). Ce principe est né de manière concomitante à :

• La naissance des langages de programmation.

• Les grands projets informatiques, nécessitants des millions de lignes de code.

• Le travail engageant de vastes ou nombreuses équipes de développement.

Il n'est pas question que chaque programmeur de la même équipe ou chaque équipe travaillant sur le même projet développe l'écriture de la même fonction chacun de son côté, multipliant les risques d'erreurs, de divergences, de structure des données à passer à la fonction et des données qu'elle doit rendre, de la précision souhaitée, de sa portabilité, etc..

Ce principe était déjà utilisé, bien que non formalisé, au début des années 1970, par simple logique (logique qui semblait, à l'époque et à bien des égards, totalement absente).

Lorsque l'auteur d'Assiste.com faisait du conseil et de l'analyse pour ses clients, alors que le développement était distribué entre plusieurs programmeurs, voire plusieurs équipes de programmeurs, des fonctions communes à tout ou partie des programmes du projet émergent et sont développées de manière commune et uniforme.

J'imposais ce principe dès 1972. Les langages que j'utilisais à l'époque étaient :

• Assembleur.
• Cobol.
• Fortran.

Hors du DRY, chacun aurait écrit ces mêmes fonctions, pourtant communes et à priori identiques, à sa sauce, directement dans le code principal des applications.

On a besoin des mêmes « routines » (des mêmes séquences d'instructions), de très nombreuses fois, au sein d'une unique application et, plus encore, à travers toutes les applications d'un même projet. Le principe de développer des briques logiciels, des bibliothèques de fonctions et services, vient de cette observation, dopée aux fantasmes du bon sens des (bons) informaticiens :

• Ne pas réécrire 36 fois la même chose (éviter la redondance de codes à travers tout un projet, voire toute la production logicielle de l'éditeur) de manière à gagner du temps et de la place en mémoire, d'autant que dans les années 1970, la mémoire coûtait une fortune et sa taille était microscopique.

• Écrire un segment de code une bonne fois pour toutes, de manière parfaite et universelle (documenté, non ambigüe, optimisé...).

• Gagner en vitesse de développement.

• Gagner en fiabilité et stabilité (s'appuyer sur des fondations éprouvées).

• Gagner en vitesse de débogage et tests (élever son point de vue et se concentrer sur la conception et l'architecture du projet et de chaque application du projet).

• Gagner en maintenance et évolution (documentation, universalité, portabilité...).

• Gagner du temps, donc de l'argent.