Je sais très peu de choses sur les DLL et les LIB sauf qu'ils contiennent le code vital requis pour qu'un programme fonctionne correctement - les bibliothèques. Mais pourquoi les compilateurs les génèrent-ils? Ne serait-il pas plus facile d'inclure tout le code dans un seul exécutable? Et quelle est la différence entre DLL et LIB?Fichiers DLL et LIB - quoi et pourquoi?
Il existe des bibliothèques statiques (LIB) et des bibliothèques dynamiques (DLL).
Les bibliothèques sont utilisées car vous pouvez avoir du code que vous souhaitez utiliser dans de nombreux programmes. Par exemple, si vous écrivez une fonction qui compte le nombre de caractères dans une chaîne, cette fonction sera utile dans beaucoup de programmes. Une fois que cette fonction fonctionne correctement, vous ne voulez pas avoir à recompiler le code chaque fois que vous l'utilisez, donc vous mettez le code exécutable de cette fonction dans une bibliothèque et l'éditeur de liens peut extraire et insérer le code compilé dans votre programme . Les bibliothèques statiques sont parfois appelées «archives» pour cette raison.
Les bibliothèques dynamiques vont encore plus loin. Il semble inutile d'avoir plusieurs copies des fonctions de la bibliothèque occupant de la place dans chacun des programmes. Pourquoi ne peuvent-ils pas tous partager une copie de la fonction? C'est ce à quoi servent les bibliothèques dynamiques. Plutôt que de construire le code de la bibliothèque dans votre programme lorsqu'il est compilé, il peut être exécuté en le mappant dans votre programme lorsqu'il est chargé en mémoire. Plusieurs programmes s'exécutant en même temps et utilisant les mêmes fonctions peuvent tous partager une copie, ce qui permet d'économiser de la mémoire. En fait, vous pouvez charger des bibliothèques dynamiques uniquement selon les besoins, en fonction du chemin parcouru par votre code. Il n'est pas utile que les routines de l'imprimante prennent de la mémoire si vous n'effectuez aucune impression. D'un autre côté, cela signifie que vous devez avoir une copie de la bibliothèque dynamique installée sur chaque machine sur laquelle votre programme s'exécute. Cela crée son propre ensemble de problèmes. A titre d'exemple, presque tous les programmes écrits en 'C' auront besoin de fonctions d'une bibliothèque appelée 'bibliothèque d'exécution C, bien que peu de programmes auront besoin de toutes les fonctions. Le moteur d'exécution C est disponible en versions statique et dynamique, ce qui vous permet de déterminer la version utilisée par votre programme en fonction des besoins particuliers.
Une raison importante pour créer un DLL/LIB plutôt que de simplement compiler le code dans un exécutable est la réutilisation et la relocalisation. L'application Java ou .NET moyenne (par exemple) utilisera très probablement plusieurs bibliothèques tierces (ou frameworks). Il est beaucoup plus facile et plus rapide de compiler uniquement avec une bibliothèque pré-compilée, plutôt que d'avoir à compiler tout le code tiers dans votre application. La compilation de votre code dans les bibliothèques encourage également les bonnes pratiques de conception, par ex. concevoir vos classes pour être utilisées dans différents types d'applications.
Un autre aspect est la sécurité (obfuscation). Une fois qu'un morceau de code est extrait de l'application principale et placé dans une bibliothèque Dynamic-Link "séparée", il est plus facile d'attaquer, d'analyser (désosser) le code, puisqu'il a été isolé. Lorsque le même morceau de code est conservé dans une bibliothèque LIB, il fait partie de l'application cible (liée) compilée, et il est donc plus difficile d'isoler (différencier) ce morceau de code du reste des binaires cibles.
L'aspect sécurité était nouveau pour moi. Le raisonnement ci-dessus est-il vrai dans le cas d'une application C# appelant une DLL C++ native non managée? – Martin
Mais le LIB est isolé aussi, n'est-ce pas? Ainsi, un attaquant pourrait simplement analyser le LIB. Ou est-ce un scénario courant que le LIB n'est pas accessible au public? –
le LIB est aussi "isolé" en ce qui concerne le processus du compilateur, mais une fois que le lieur a assemblé les parties, le LIB fait partie de l'EXE et ne peut pas être différencié de votre propre code. – mox
Une DLL est une bibliothèque de fonctions partagées entre d'autres programmes exécutables. Il suffit de regarder dans votre répertoire windows/system32 et vous trouverez des dizaines d'entre eux. Lorsque votre programme crée une DLL, il crée également normalement un fichier lib afin que le programme * .exe de l'application puisse résoudre les symboles déclarés dans la DLL. Un .lib est une bibliothèque de fonctions qui sont liées statiquement à un programme - elles ne sont PAS partagées par d'autres programmes. Chaque programme qui lie avec un fichier * .lib a tout le code dans ce fichier. Si vous avez deux programmes A.exe et B.exe qui se lient à C.lib alors chaque A et B contiendront le code dans C.lib.
La façon dont vous créez des DLL et des bibliothèques dépend du compilateur que vous utilisez. Chaque compilateur le fait différemment.
Une autre différence réside dans les performances. Comme la DLL est chargée à l'exécution par le (s) .exe (s), le .exe (s) et le DLL fonctionnent avec le concept de mémoire partagée et donc les performances sont faibles par rapport à la liaison statique. D'autre part, un .lib est un code qui est lié statiquement au moment de la compilation dans chaque processus qui demande. D'où le .exe (s) aura une mémoire unique, ce qui augmente la performance du processus.
Il s'avère que les fichiers '.LIB' peuvent être des bibliothèques statiques (contenant des fichiers objet) ou des bibliothèques d'importation (contenant des symboles pour permettre à l'éditeur de liens de se lier à une DLL). [Je me demande pourquoi c'est ainsi.] (Http://stackoverflow.com/q/6421693/269126) – Lumi
bonne explication! Le code est partagé et les données (par défaut) ne sont pas partagées entre les applications consommant une DLL. – mox