étant donné que les DLL sont essentiellement les mêmes que les Exe, le choix de produire dans le cadre du processus de liaison est pour plus de clarté, car il est possible d’exporter des fonctions et des données de l’un ou l’autre.

Il n’est pas possible d’exécuter directement une DLL, car elle nécessite un EXE pour que le système d’exploitation le charge via un point d’entrée, d’où l’existence d’utilitaires comme RUNDLL.EXE ou RUNDLL32.EXE qui fournissent le point d’entrée et le cadre minimal pour les DLL qui contiennent suffisamment de fonctionnalités pour s’exécuter sans beaucoup de support.,

les DLL fournissent un mécanisme pour le code et les données partagés, permettant à un développeur de code/données partagés de mettre à niveau les fonctionnalités sans nécessiter de re-lien ou de re-compilation des applications. Du point de vue du développement d’Applications, Windows et OS/2 peuvent être considérés comme une collection de DLL mises à niveau, permettant aux applications d’une version du système d’exploitation de fonctionner dans une version ultérieure, à condition que le fournisseur du système d’exploitation s’assure que les interfaces et les fonctionnalités sont compatibles.,

Les DLL s’exécutent dans l’espace mémoire du processus appelant et avec les mêmes autorisations d’accès, ce qui signifie qu’il y a peu de surcharge dans leur utilisation, mais aussi qu’il n’y a pas de protection pour L’exe appelant si la DLL a une sorte de bogue.

Memory managementEdit

dans L’API Windows, les fichiers DLL sont organisés en sections. Chaque section A son propre ensemble d’attributs, tels que l’écriture ou la lecture seule, exécutable (pour le code) ou non exécutable (pour les données), etc.,

le code d’une DLL est généralement partagé entre tous les processus qui utilisent la DLL; c’est-à-dire qu’ils occupent une seule place dans la mémoire physique et ne prennent pas de place dans le fichier de page. Windows n’utilise pas de code indépendant de la position pour ses DLL; au lieu de cela, le code subit une relocalisation au fur et à mesure du chargement, fixant les adresses de tous ses points d’entrée à des emplacements libres dans l’espace mémoire du premier processus pour charger la DLL., Dans les anciennes versions de Windows, dans lesquelles tous les processus en cours d’exécution occupaient un seul espace d’adressage commun, une seule copie du code de la DLL serait toujours suffisante pour tous les processus. Cependant, dans les versions plus récentes de Windows qui utilisent des espaces d’adressage séparés pour chaque programme, il n’est possible d’utiliser la même copie relocalisée de la DLL dans plusieurs programmes que si chaque programme a les mêmes adresses virtuelles libres pour accueillir le code de la DLL., Si certains programmes (ou leur combinaison de DLL déjà chargées) n’ont pas ces adresses libres, alors une copie physique supplémentaire du code de la dll devra être créée, en utilisant un ensemble différent de points d’entrée déplacés. Si la mémoire physique occupée par une section de code doit être récupérée, son contenu est supprimé, puis rechargé directement à partir du fichier DLL si nécessaire.

contrairement aux sections de code, les sections de données d’une DLL sont généralement privées; c’est-à-dire que chaque processus utilisant la DLL a sa propre copie de toutes les données de la DLL., En option, des sections de données peuvent être partagées, permettant une communication inter-processus via cette zone de mémoire partagée. Cependant, étant donné que les restrictions utilisateur ne s’appliquent pas à l’utilisation de la mémoire DLL partagée, cela crée une faille de sécurité; à savoir, un processus peut corrompre les données partagées, ce qui entraînera probablement un comportement indésirable de tous les autres processus de partage. Par exemple, un processus exécuté sous un compte invité peut ainsi corrompre un autre processus exécuté sous un compte privilégié. C’est une raison importante pour éviter l’utilisation de sections partagées dans les Dll.,

Si une DLL est compressée par certains packers exécutables (par exemple UPX), toutes ses sections de code sont marquées en lecture et en écriture, et ne seront pas partagées. Les sections de code en lecture et en écriture, tout comme les sections de données privées, sont privées pour chaque processus. Ainsi, les DLL avec des sections de données partagées ne doivent pas être compressées si elles sont destinées à être utilisées simultanément par plusieurs programmes, car chaque instance de programme devrait porter sa propre copie de la DLL, ce qui entraînerait une consommation de mémoire accrue.

Importer librariesEdit

Comme statiques des bibliothèques, bibliothèques d’importation pour les Dll sont notées par l’ .,extension de fichier lib. Par exemple, kernel32.dll, la Bibliothèque dynamique principale pour les fonctions de base de Windows telles que la création de fichiers et la gestion de la mémoire, est liée via kernel32.lib. La façon habituelle de dire à une bibliothèque d’importation à partir d’une bibliothèque statique appropriée est par taille: la bibliothèque d’importation est beaucoup plus petite car elle ne contient que des symboles faisant référence à la DLL réelle, à traiter au moment du lien. Les deux sont néanmoins des fichiers au format ar Unix.

la liaison à des bibliothèques dynamiques est généralement gérée en reliant à une bibliothèque d’importation lors de la création ou de la liaison pour créer un fichier exécutable., L’exécutable créé contient ensuite une table d’adresses d’importation (IAT) par laquelle tous les appels de fonction DLL sont référencés (chaque fonction DLL référencée contient sa propre entrée dans L’IAT). Au moment de l’exécution, L’IAT est rempli d’adresses appropriées qui pointent directement vers une fonction dans la DLL chargée séparément.

dans Cygwin/MSYS et MinGW, les bibliothèques d’importation reçoivent classiquement le suffixe.dll.a, combinant à la fois le suffixe DLL Windows et le suffixe ar Unix., Le format de fichier est similaire, mais les symboles utilisés pour marquer les importations sont différents (_head_foo_dll vs __IMPORT_DESCRIPTOR_foo). Bien que sa chaîne D’outils GNU Binutils puisse générer des bibliothèques d’importation et les lier, il est plus rapide de les lier directement à la DLL. Un outil expérimental dans MinGW appelé genlib peut être utilisé pour générer des bibliothèques d’importation avec des symboles de style MSVC.

Symbol resolution and bindingEdit

chaque fonction exportée par une DLL est identifiée par un ordinal numérique et éventuellement un nom. De même, les fonctions peuvent être importées à partir d’une DLL soit par ordinal, soit par nom., L’ordinal représente la position du pointeur d’adresse de la fonction dans la table D’adresses D’exportation de la DLL. Il est courant que les fonctions internes soient exportées uniquement par ordinal. Pour la plupart des fonctions de L’API Windows, seuls les noms sont conservés dans différentes versions de Windows; les ordinaux sont sujets à changement. Ainsi, on ne peut pas importer de manière fiable les fonctions de L’API Windows par leurs ordinaux.

importer des fonctions par ordinal n’offre que des performances légèrement meilleures que de les importer par nom: les tables d’exportation de DLL sont classées par nom, une recherche binaire peut donc être utilisée pour trouver une fonction., L’index du nom trouvé est ensuite utilisé pour rechercher l’ordinal dans la table ordinale D’exportation. Dans Windows 16 bits, la table de noms n’était pas triée, donc la surcharge de recherche de noms était beaucoup plus visible.

Il est également possible de lier un exécutable à une version spécifique d’une DLL, c’est-à-dire de résoudre les adresses des fonctions importées au moment de la compilation. Pour les importations liées, l’éditeur de liens enregistre l’horodatage et la somme de contrôle de la DLL à laquelle l’importation est liée. Au moment de l’exécution, Windows vérifie si la même version de la Bibliothèque est utilisée et, dans l’affirmative, Windows contourne le traitement des importations., Sinon, si la Bibliothèque est différente de celle à laquelle elle était liée, Windows traite les importations de manière normale.

les exécutables liés se chargent un peu plus rapidement s’ils sont exécutés dans le même environnement pour lequel ils ont été compilés, et exactement au même moment s’ils sont exécutés dans un environnement différent, il n’y a donc aucun inconvénient à lier les importations. Par exemple, toutes les applications Windows standard sont liées aux DLL système de leur version Windows respective. Une bonne occasion de lier les importations d’une application à son environnement cible est lors de l’installation de l’application., Cela maintient les bibliothèques « liées » jusqu’à la prochaine mise à jour du système d’exploitation. Cependant, il modifie la somme de contrôle de l’exécutable, ce n’est donc pas quelque chose qui peut être fait avec des programmes signés ou des programmes gérés par un outil de gestion de la configuration qui utilise des sommes de contrôle (telles que les sommes de contrôle MD5) pour gérer les versions de fichiers. Comme les versions plus récentes de Windows ont cessé d’avoir des adresses fixes pour chaque bibliothèque chargée (pour des raisons de sécurité), la possibilité et la valeur de lier un exécutable diminuent.,

explicit run-time linkingEdit

les fichiers DLL peuvent être chargés explicitement au moment de l’exécution, un processus appelé simplement liaison dynamique au moment de l’exécution par Microsoft, en utilisant la fonction APILoadLibrary (ouLoadLibraryEx). La fonction APIGetProcAddress est utilisée pour rechercher les symboles exportés par nom, etFreeLibrary – pour décharger la DLL. Ces fonctions sont analogues à dlopen, dlsym et dlclose dans la norme POSIX API.,

la procédure de liaison explicite à l’exécution est la même dans tous les langages prenant en charge les pointeurs vers les fonctions, car elle dépend de L’API Windows plutôt que des constructions de langage.

Delayed loadingEdit

normalement, une application liée à la bibliothèque d’importation d’une DLL ne démarre pas si la DLL est introuvable, car Windows n’exécutera pas L’application à moins de trouver toutes les DLL dont l’application peut avoir besoin. Cependant, une application peut être liée à une bibliothèque d’importation pour permettre le chargement retardé de la Bibliothèque dynamique.,Dans ce cas, le système d’exploitation n’essaiera pas de trouver ou de charger la DLL au démarrage de l’application; à la place, un talon est inclus dans l’application par l’éditeur de liens qui essaiera de trouver et de charger la dll via LoadLibrary et GetProcAddress lorsqu’une de ses fonctions est appelée. Si la DLL ne peut pas être trouvée ou chargée, ou si la fonction appelée n’existe pas, l’application générera une exception, qui peut être interceptée et gérée de manière appropriée. Si l’application ne gère pas l’exception, elle sera interceptée par le système d’exploitation, qui mettra fin au programme avec un message d’erreur.,

le mécanisme de chargement différé fournit également des crochets de notification, permettant à l’application d’effectuer un traitement supplémentaire ou une gestion des erreurs lorsque la DLL est chargée et/ou qu’une fonction DLL est appelée.