Que contient un DLL et comment ça marche?
Je fais toujours référence à des DLL dans mon code C #, mais elles sont restées un peu un mystère que je voudrais clarifier. Il s'agit d'une sorte de réflexion sur les DLL.
Je comprends un DLL est une bibliothèque liée dynamiquement qui signifie qu'un autre programme peut accéder à cette bibliothèque au moment de l'exécution pour obtenir des "fonctionnalités". Cependant, considérez le projet ASP.NET suivant avec Web.dll et Business.dll (Web.dll est la fonctionnalité frontale et fait référence à Business.dll pour les types et les méthodes).
À quel moment
Web.dllEst-il lié dynamiquement àBusiness.dll? Vous remarquez beaucoup de débordements de disques durs Windows pour des tâches apparemment petites lors de l'utilisation de Word (etc.) et je pense que Word s'éteint et lie dynamiquement les fonctionnalités d'autres DLL?1a. De plus, qu'est-ce qui charge et relie le DLL - le système d'exploitation ou un cadre d'exécution tel que le cadre .NET?
1b. Quel est le processus de "liaison"? Des vérifications de compatibilité sont-elles effectuées? Chargement dans la même mémoire? Que signifie réellement le lien?
Qu'est-ce qui exécute réellement le code dans la DLL? Est-il exécuté par le processeur ou existe-t-il une autre étape de traduction ou de compilation avant que le processeur comprenne le code à l'intérieur de la DLL?
2a. Dans le cas d'un DLL construit en C # .NET, qu'est-ce qui s'exécute: le framework .NET ou le système d'exploitation directement?
Un DLL de Linux fonctionne-t-il sur un système Windows (si une telle chose existe), ou sont-ils spécifiques au système d'exploitation?
Les DLL sont-elles spécifiques à un cadre particulier? Un DLL construit avec C # .NET peut-il être utilisé par un DLL construit avec, par exemple, Borland C++?)
4a. Si la réponse à 4 est "non", quel est l'intérêt d'une DLL? Pourquoi les différents frameworks n'utilisent-ils pas leurs propres formats pour les fichiers liés? Par exemple: un .exe intégré à .NET sait qu'un type de fichier .abc est quelque chose qu'il peut lier à son code.
Pour revenir à l'exemple
Web.dll/Business.dll- pour obtenir un type de client de classe, je dois référencerBusiness.dllÀ partir deWeb.dll. Cela doit signifier queBusiness.dllContient une sorte de spécification sur ce qu'est réellement une classe de clients. Si j'avais compilé mon fichierBusiness.dllDans, disons, Delphi: est-ce que C # le comprendrait et serait capable de créer une classe client, ou y a-t-il une sorte d'information d'en-tête ou quelque chose qui dit "hé désolé, vous ne pouvez utiliser que moi d'une autre DLL Delphi "?5a. Il en va de même pour les méthodes; puis-je écrire une méthode
CreateInvoice()dans une DLL, la compiler en C++, puis y accéder et l'exécuter à partir de C #? Qu'est-ce qui m'empêche ou me permet de faire cela?Au sujet de DLL détournement, sûrement le remplacement (mauvais) DLL doit contenir les signatures et types de méthode exacts comme celui qui est détourné. Je suppose que cela ne serait pas difficile à faire si vous pouviez découvrir quelles méthodes étaient disponibles dans la DLL d'origine.
6a. Que décide mon programme C # si je peux accéder à une autre DLL? Si mon piraté DLL contenait exactement les mêmes méthodes et types que l'original mais qu'il était compilé dans une autre langue, cela fonctionnerait-il?
Qu'est-ce que DLL importation et DLL enregistrement?)
Tout d'abord, vous devez comprendre la différence entre deux types de DLL très différents. Microsoft a décidé d'utiliser les mêmes extensions de fichier (.exe et .dll) avec .NET (code managé) et le code natif, mais les DLL de code managé et les DLL natives sont très différentes à l'intérieur.
1) À quel moment web.dll est-il lié dynamiquement à business.dll? Vous remarquez beaucoup de débordements de disques durs Windows pour des tâches apparemment petites lors de l'utilisation de Word, etc. et je pense que ce mot se déclenche et lie dynamiquement les fonctionnalités d'autres DLL?
1) Dans le cas de .NET, les DLL sont généralement chargées à la demande lorsque la première méthode essayant d'accéder à quoi que ce soit à partir de DLL est exécutée. C'est pourquoi vous pouvez obtenir TypeNotFoundExceptions n'importe où dans votre code si a DLL ne peut pas être chargé. Quand quelque chose comme Word commence soudainement à accéder au disque dur, il est probable qu'il permute (obtenir des données qui ont été échangées sur le disque pour faire de la place dans la RAM))
1a) De plus, qu'est-ce qui charge et relie le DLL - le O/S ou un framework d'exécution tel que le framework .Net?
1a) Dans le cas des DLL managées, le framework .NET est ce qui se charge, JIT compile (compile le bytecode .NET en code natif) et relie les DLL. Dans le cas des DLL natives, c'est un composant du système d'exploitation qui charge et relie le DLL (aucune compilation n'est nécessaire car les DLL natives contiennent déjà du code natif).
1b) Quel est le processus de "liaison"? Des contrôles sont-ils effectués pour vérifier la compatibilité? Chargement dans la même mémoire? Que signifie réellement le lien?
1b) La liaison se produit lorsque des références (par exemple des appels de méthode) dans le code appelant à des symboles (par exemple des méthodes) dans DLL sont remplacées par les adresses réelles des éléments de la DLL. Cela est nécessaire car les adresses éventuelles des choses dans le DLL ne peuvent pas être connues avant qu'il ne soit chargé en mémoire.
2) Qu'est-ce qui exécute réellement le code dans la DLL? Est-il exécuté par le processeur ou existe-t-il une autre étape de traduction ou de compilation avant que le processeur comprenne le code à l'intérieur de la DLL?
2) Sous Windows, les fichiers .exe et .dll sont assez identiques. Les fichiers natifs .exe et .dll contiennent du code natif (la même chose que le processeur exécute), il n'est donc pas nécessaire de traduire. Les fichiers .exe et .dll gérés contiennent le bytecode .NET qui est d'abord compilé JIT (traduit en code natif).
2a) Dans le cas d'un DLL construit à partir de C # .net, qu'est-ce qui l'exécute? Le framework .Net ou le système d'exploitation directement?
2a) Une fois que le code a été compilé JIT, il est exécuté exactement de la même manière que n'importe quel code.
3) Est-ce qu'un DLL de disons Linux fonctionne sur un système Windows (si une telle chose existe) ou sont-ils spécifiques au système d'exploitation?
3) Les DLL gérées peuvent fonctionner telles quelles, tant que les cadres des deux plates-formes sont à jour et que celui qui a écrit le DLL n'a pas délibérément rompu la compatibilité en utilisant des appels natifs. Les DLL natives ne fonctionne pas tel quel, car les formats sont différents (même si le code machine à l'intérieur est le même, s'ils sont tous les deux pour la même plate-forme de processeur). Soit dit en passant, sous Linux, les "DLL" sont appelées .so ( fichiers partagés).
4) Sont-ils spécifiques à un cadre particulier? Un DLL construit avec C # .Net peut-il être utilisé par un DLL construit avec Borland C++ (exemple uniquement))?
4) Les DLL managées sont particulières au framework .NET, mais elles fonctionnent naturellement avec n'importe quel langage compatible. Les DLL natives sont compatibles tant que tout le monde utilise les mêmes conventions (conventions d'appel (comment les arguments de fonction sont passés au niveau du code machine), dénomination des symboles, etc.)
5) Revenons à l'exemple web.dll/business.dll. Pour obtenir un type de client de classe, je dois référencer business.dll à partir de web.dll. Cela doit signifier que business.dll contient une spécification d'une sorte de ce qu'est réellement une classe client. Si j'avais compilé mon fichier business.dll en disant que Delphi le comprendrait et serait capable de créer une classe client - ou y a-t-il une sorte d'informations d'en-tête ou quelque chose qui dit "hé désolé, vous ne pouvez m'utiliser qu'à partir d'une autre dll delphi" .
5) Les DLL gérées contiennent une description complète de chaque classe, méthode, champ, etc. qu'elles contiennent. AFAIK Delphi ne prend pas en charge .NET, il créerait donc des DLL natives, qui ne peuvent pas être utilisées directement dans .NET. Vous pourrez probablement appeler des fonctions avec PInvoke, mais les définitions de classe ne seront pas trouvées. Je n'utilise pas Delphi, donc je ne sais pas comment il stocke les informations de type avec les DLL. C++, par exemple, s'appuie sur des fichiers d'en-tête (.h) qui contiennent les déclarations de type et doivent être distribués avec la DLL.
6) Au sujet du DLL détournement, le remplacement (mauvais) DLL doit sûrement contenir les signatures de méthode exactes, des types comme celui qui est détourné). Je suppose que ce ne serait pas difficile à faire si vous pouviez savoir quelles méthodes, etc. étaient disponibles dans la DLL d'origine.
6) En effet, ce n'est pas difficile à faire si vous pouvez facilement changer de DLL. La signature de code peut être utilisée pour éviter cela. Pour que quelqu'un puisse remplacer une DLL signée, il doit connaître la clé de signature, qu'elle a gardée secrète.
6a) Un peu de répétition ici, mais cela revient à ce que dans mon programme C # décide si je peux accéder à une autre DLL? Si mon DLL détourné contenait exactement les mêmes méthodes et types que l'original mais qu'il était compilé dans une autre langue, cela fonctionnerait-il?
6a) Cela fonctionnerait tant qu'il s'agit d'une DLL gérée, créée avec n'importe quel langage .NET.
- Qu'est-ce que DLL importation? Et enregistrement dll?
"L'importation de DLL" peut signifier beaucoup de choses, généralement cela signifie référencer un fichier DLL et y utiliser des choses).
L'enregistrement de DLL est quelque chose qui est fait sur Windows pour enregistrer globalement les fichiers DLL en tant que composants COM pour les rendre disponibles à tout logiciel sur le système.
Un fichier .dll contient du code compilé que vous pouvez utiliser dans votre application.
Parfois, l'outil utilisé pour compiler le fichier .dll est important, parfois non. Si vous pouvez référencer le .dll dans votre projet, peu importe quel outil a été utilisé pour coder les fonctions exposées du .dll.
La liaison se produit au moment de l'exécution, contrairement aux bibliothèques liées statiquement, telles que vos classes, qui se lient au moment de la compilation.
Vous pouvez considérer un .dll comme une boîte noire qui fournit quelque chose dont votre application a besoin et que vous ne voulez pas écrire vous-même. Oui, quelqu'un qui comprend la signature du .dll pourrait créer un autre fichier .dll avec un code différent à l'intérieur et votre application appelante ne pourrait pas faire la différence.
HTH
1) À quel moment web.dll est-il lié dynamiquement à business.dll? Vous remarquez beaucoup de débordements de disques durs Windows pour des tâches apparemment petites lors de l'utilisation de Word, etc. et je pense que ce mot se déclenche et lie dynamiquement les fonctionnalités d'autres DLL?
1) Je pense que vous confondez la liaison avec le chargement. Le lien est lorsque tous les freins et contrepoids sont testés pour s'assurer que ce qui est demandé est disponible. Au moment du chargement, des parties de la DLL sont chargées en mémoire ou échangées vers le fichier d'échange. C'est l'activité HD que vous voyez.
La liaison dynamique est différente de la liaison statique en ce que dans la liaison statique, tout le code objet est placé dans le fichier .exe principal au moment de la liaison. Avec la liaison dynamique, le code objet est placé dans un fichier distinct (la dll) et il est chargé à un moment différent du .exe.
La liaison dynamique peut être implicite (c'est-à-dire les liens de l'application avec une bibliothèque d'importation) ou explicite (c'est-à-dire que l'application utilise LoadLibrary (ex) pour charger la DLL).
Dans le cas implicite,/DELAYLOAD peut être utilisé pour reporter le chargement de la DLL jusqu'à ce que l'application en ait réellement besoin. Sinon, au moins certaines parties de celui-ci sont chargées (mappées dans l'espace d'adressage du processus) dans le cadre de l'initialisation du processus. La DLL peut également demander qu'elle ne soit jamais déchargée pendant que le processus est actif.
COM utilise LoadLibrary pour charger les DLL COM. Notez que même dans le cas implicite, le système utilise quelque chose de similaire à LoadLibrary pour charger la DLL soit au démarrage du processus, soit lors de la première utilisation.
2) Qu'est-ce qui exécute réellement le code dans la DLL? Est-il exécuté par le processeur ou existe-t-il une autre étape de traduction ou de compilation avant que le processeur comprenne le code à l'intérieur de la DLL?
2) Les DLL contiennent du code objet tout comme .exes. Le format du fichier dll est presque identique au format d'un fichier exe. J'ai entendu dire qu'il n'y a qu'un seul élément différent dans les en-têtes des deux fichiers.
Dans le cas d'un DLL construit à partir de C # .net, le framework .Net l'exécute.
3) Est-ce qu'un DLL de disons Linux fonctionne sur un système Windows (si une telle chose existe) ou sont-ils spécifiques au système d'exploitation?
3) Les DLL sont spécifiques à la plate-forme.
4) Sont-ils spécifiques à un cadre particulier? Un DLL construit avec C # .Net peut-il être utilisé par un DLL construit avec Borland C++ (exemple uniquement))?
4) Les DLL peuvent interagir avec d'autres frameworks si des précautions particulières sont prises ou si un code de colle supplémentaire est écrit.
Les DLL sont très utiles lorsqu'une entreprise vend plusieurs produits ayant des capacités qui se chevauchent. Par exemple, je maintiens une dll d'E/S raster utilisée par plus de 30 produits différents dans l'entreprise. Si plusieurs produits sont installés, une mise à niveau de la DLL peut mettre à niveau tous les produits vers de nouveaux formats raster.
5) Revenons à l'exemple web.dll/business.dll. Pour obtenir un type de client de classe, je dois référencer business.dll à partir de web.dll. Cela doit signifier que business.dll contient une spécification d'une sorte de ce qu'est réellement une classe client. Si j'avais compilé mon fichier business.dll en disant que Delphi le comprendrait et serait capable de créer une classe client - ou y a-t-il une sorte d'informations d'en-tête ou quelque chose qui dit "hé désolé, vous ne pouvez m'utiliser qu'à partir d'une autre DLL delphi" .
5) Selon la plate-forme, les capacités d'une DLL sont présentées de différentes manières, à travers des fichiers .h, des fichiers .tlb ou d'autres manières sur .net.
6) Au sujet du DLL détournement, le remplacement (mauvais) DLL doit sûrement contenir les signatures de méthode exactes, des types comme celui qui est détourné). Je suppose que ce ne serait pas difficile à faire si vous pouviez savoir quelles méthodes, etc., étaient disponibles dans la DLL d'origine.
6) dumpbin/exports et dumbin/imports sont des outils intéressants à utiliser sur .exe et .dlls