Version imprimable
Salut à tous.
Quel est la différence à l'usage entre une bibliothèque dynamique et une bibliothèque d'importation !
Je parle aussi bien du 'C' que du 'C++'.
Je trouve que l'usage de la bibliothèque d'importation est très proche de celle de la bibliothèque statique.
Quand à la bibliothèque dynamique, je trouve cela plutôt lourd pour un usage non pertinent.
Peut on me donner un exemple d'usage où la bibliothèque dynamique serait mieux que la bibliothèque d'importation ?
Bonjour.
Si tu poses la question c'est que je suppose que tu es sous Windows (le "problème" n'existe pas sous linux).
La vraie différence se situe entre bibliothèque dynamique et statique :
- dynamique : le code exécutable de la bibliothèque est chargée lors de l'exécution de l'application ;
- statique : le code d'exécution de la bibliothèque est intégrée au code de l'exécutable (fichier .exe beaucoup plus gros)
Lorsque tu cites dynamique et d'importation dans les faits ils sont liés :
- importation : .lib sert au compilateur pour lier les fonctions de la bibliothèque à l'application (il utilise aussi le .h) ;
- dynamique : .dll code d'exécution de la bibliothèque chargée lors du lancement de l'application.
Comme le dit @gerald3d, la bibliothèque statique est rajoutée dans l'exécutable.
Cela fait des exécutables + gros, mais + portables parce que tu n'as pas dépendances (du moins - de dépendances)
L'autre différence (qui est lié à l'exécution d'un exécutable), avec une bibliothèque dynamique, lorsque tu appelles une fonction dedans, le système d'exploitation va regarder si cette fonction est en mémoire, sinon la charge, et l'appelle.
Donc il ne va charger que les parties que tu as besoin et non l'intégralité de ta bibliothèque.
Salut à tous.
Merci pour vos réponses. :)
@ Gerald3d : oui, je suis sous windows 10 Pro.
Sauf que vous m'expliquez comment cela fonctionne alors que je cherche à savoir dans quel cas, fait on l'usage de tel ou tel bibliothèque.
Je ne m'intéresse pas ici à la bibliothèque statique.
Je cherche à comprendre dans quel cas va-t-on privilégier la bibliothèque d'importation par rapport à la bibliothèque dynamique.
Je trouve que la bibliothèque dynamique est lourde à l'usage et je ne comprends pas trop dans quel cas l'utiliser.
Inversement, je trouve que la bibliothèque d'importation est plus souple à l'usage et plus simple à développer.
Pouvez vous me donner un usage pour chacune de ces deux bibliothèque ?
Je suppose que s'il ces bibliothèques existent, il y a un besoin réel, non ?
Effectivement je n'ai pas vraiment répondu à la question, du moins en toute petite partie. @foetus apporte un début de réponse.
Si j'ai donné l'explication de qui fait quoi c'est simplement parce que j'ai l'impression, ou c'est moi qui suis totalement à côté, que tu utilises des termes qui veulent dire la même chose. Bibliothèque dynamique et d'importation sont pour moi la même chose. Si tu utilises une bibliothèque d'importation c'est qu'en réalité tu utilises forcément une bibliothèque dynamique. La bibliothèque d'importation est utilisée lors du "linkage" du compilateur avec une bibliothèque dynamique.
Donc, en résumé il n'y a que deux types de bibliothèque :
- dynamique : l'exécutable doit être accompagné des fichiers des bibliothèques utilisées ;
- statique : tout le code est contenu dans l'exécutable.
Maintenant dans quel cas utiliser l'une ou l'autre ?
Ce n'est pas forcément évident de répondre à cette question mais je vais essayer de donner un exemple pour chacune :
- statique : une application de type zip qui est capable de compacter des données et de générer en même temps un exécutable. L'utilisateur final n'a pas besoin d'installer les outils nécessaires. L'exécutable intègre tous les outils de décompactage ainsi que les données à traiter ;
- dynamique : un bon exemple est les jeux vidéos. Ils installent dans un répertoire personnel les bibliothèques qui pourtant existent déjà sur le système. Mais ils installent une version adaptée à leur fonctionnement. Ceci évite les conflits liés à la version du système d'exploitation et assure que l'application fonctionnera à peu prés sur toutes les machines. Si je prends mon cas je programme sous linux avec Gtk. Si je devais porter mon application sous Windows je devrais forcément installer Gtk sous cet environnement, ce qui n'est pas à priori facile. Comme Gtk est relativement imposant je ne me vois pas l'intégrer en statique.
Bonjour,
Les DLL offrent des possibilités que n'offrent pas les bibliothèques statiques :
- Tant que les fonctions gardent les mêmes caractéristiques, elles peuvent évoluer (corrections, accélérations...) sans retoucher à l'application principale.
- Elles sont partageables par plusieurs applications sans nécessiter leurs démultiplications : par exemple, les pilotes.
- Elles peuvent être chargées en différé (même si la très grande majorité des applications le fait au démarrage) : par exemple, ne charger que la version optimisée pour le processeur et l'environnement d'exécution.
- Elles peuvent partager une interface commune définie par l'application pour offrir des fonctions différentes : par exemple les plugins de GIMP et autres...
En revanche, l'appel des fonctions des DLL subit une indirection de plus que la même fonction intégrée. Ce n'est donc pas indiqué pour des micro-fonctions.
Si on vise la réutilisation possible, la conception des DLL est plus complexe, ne serait-ce que parce que la DLL ne peut alors présupposer l'environnement applicatif qui l'appelle. Par exemple, la qualité des arguments passés à ses fonctions doit être contrôlée alors que l'appelant l'a peut-être déjà fait.
Salutations
MSDN précise que les bibliothèques d'importation c'est l'outil LIB.exe : LIB Reference en anglaisCitation:
Envoyé par gerald3d
bibliothèque d'importation est la traduction de "import library" que l'on peut lire en français en changeant le en-us du lien MSDN par fr-frCitation:
LIB (lib.exe) creates standard libraries, import libraries, and export files you can use with LINK when building a program. (dans la section overview of LIB/ vue d'ensemble de LIB)
Techniquement il y a 3 types de bibliothèque sous Windows : 3) "shared libraries"Citation:
Envoyé par gerald3d
Je suis rouillé sur cette notion et Google/ IA doit l'expliquer précisément :oops: :oops: mais tu linkes statiquement la liste des fonctions/ objets d'une bibliothèque dynamique (.dll) : tu gardes l'aspect statique pour ton exécutable et en même temps, tu as une .dll que tu peux partager/ modifier.
Pas du tout, sinon je n'aurai pas ouvert ce sujet.Citation:
Envoyé par Gerald3d
J'en conviens que la différence peut venir du vocabulaire mais dans les faits, ce n'est pas la même chose, surtout au niveau du makefile.
Prenons le cas d'une bibliothèque de nom "test".
:fleche: La bibliothèque statique se nomme "libtest.a". Dans le makefile, on indique le chemin où elle se trouve et à l'édition des liens, on précise "-ltest".
:fleche: la bibliothèque dynamique se nomme "test.dll". On ne fait aucune référence à cette bibliothèque dans le makefile, mais à l'exécution, on doit préciser dans le chemin (PATH) où elle se trouve.
:fleche: la bibliothèque d'importation se nomme "test.dll". Il y a aussi "libtest.dll.a" ainsi que "-ltest" pour l'édition des liens. On précise à l'exécution le chemin où elle se trouve, comme dans le cas de la bibliothèque dynamique.
La bibliothèque d'importation est très similaire à la bibliothèque statique pour l'édition des liens, avec en plus à l'exécution, le chemin (PATH) où elle se trouve. Pour le développement, c'est quasiment pareil. Je ne vois que des avantages à son utilisation.
Voilà de ce que j'ai compris, mais le problème n'est pas là.
Il me semble que la bibliothèque dynamique est plus fait pour du développement Windows Win32, pas pour de la console.
Elle utilise les fonctions "loadLibray()" pour accéder à la bibliothèque et "GetProcAddress()" pour accéder à chaque fonction.
Sans compter les problèmes du passage des arguments qui peuvent différer.
Je trouve cela lourd et compliqué à mettre en œuvre quand tu as plusieurs fonctions gérées de cette façon là.
D'accord dans l'usage des jeux. Mais est-ce dynamique ou d'importation ? Je suppose dynamique.
Ce qui me surprend, il existe déjà des bibliothèques dynamiques dans le répertoire Windows, que l'on peut venir écraser par une nouvelle version pour des applications qui en font l'usage, sans que cela vienne perturber Windows qui en à aussi l'usage.
@ Guesset : ce que tu décris est bien la lourdeur des bibliothèques dynamiques qui s'utilisent dans un environnement Windows, à moins de me tromper à ce sujet.
@ foetus : je crois que shared library est synonyme de dynamic library.
Il y a donc bien trois types de bibliothèques : statique, dynamique et d'importation.
Est-ce que je me trompe, mais il me semble que vous ne connaissez pas les bibliothèques d'importations ?
Au temps pour moi. Je ne connaissais pas cette subtilité entre importation et dynamique.
Comme quoi on en apprend tous les jours ;).
Salut à tous,
Cela fait très longtemps que je n'avais plus remis les doigts dans la programmation Windows au niveau du C/C++ (la dernière fois, ça devait être en 2002 avec la C.API et les MFC sous Visual Studio) mais de ce que je m'en souviens et ce que j'en trouve quand je fais une recherche, il semble que :
- Les DLL sont bien les bibliothèques dynamiques sous Windows (et les même les versions récentes de DOS mais je dis ça de mémoire et j'ai peur de dire une ânerie), homologues des bibliothèques partagées sous (shared library sous Unix). Ça c'est OK pour tout le monde ;
- Les LIB sont bien les bibliothèques statiques sous Windows,
et pour le coup utilisent le même format *.a que les bibliothèques statiques Unix(en fait, OMF ou COFF selon les versions, générés avec ar mais pas sur les mêmes plateformes) ;- Les fichiers d'import sont en fait le manifeste de ce que contient une DLL (les symboles et leur points d'entrée dans le fichier) et sont nécessaires au linker parce que, pour une raison qui reste à déterminer, il n'est pas capable d'aller directement explorer la DLL concernée pour le savoir, ce qui est une spécificité du monde Windows.
Et la clé du mystère en bonus :
- Ce manifeste est une ressource qui est elle-même distribuée sous forme de bibliothèque statique, ce qui explique pourquoi le fichier porte la même extension et respecte le même format.
Donc, quand on produit une DLL, le compilateur va générer à la fois le fichier DLL et le fichier LIB qui l'accompagne, mais ce fichier LIB n'est pas la version statique de la bibliothèque. Juste le fichier d'import (le manifeste en question). Ce fichier d'import, à son tour, n'est nécessaire que pour compiler un exécutable s'appuyant sur une (ou plusieurs) DLL. Une fois produit, le fichier d'import n'est plus nécessaire.
Pourquoi cette particularité ? Je l'ignore mais on peut envisager beaucoup de raison à ça :
— La première est que la DLL proprement dite peut être très grosse et qu'il n'était pas forcément pertinent de se la trimbaler en entier dans un projet tiers si c'est uniquement pour permettre à la compilation d'aller jusqu'à son terme.
— La deuxième est que bien souvent, ces DLL étaient commerciales et qu'il coûtait cher de les acquérir et que distribuer l'interface seule était une solution qui arrangeait à la fois la société éditrice de la lib et celle qui en avait besoin pour compiler.
— La troisième est que tous les systèmes d'exploitation n'utilisent pas forcément d'interruption ou d'instruction dédiée pour déclencher des appels système. Il se peut alors que ces appels systèmes du noyau respectent la même ABI et les mêmes conventions d'appel. Dans cette situation, un même fichier d'import est nécessaire pour les invoquer mais eux ne font pas l'objet d'un fichier DLL dédié.
La bibliothèque d'importation est un intermédiaire entre ton code et une bibliothèque dynamique. Un intermédiaire qui fait tout le boulot pour toi, mais seulement pour le cas d'utilisation le plus courant: Celui où tu as besoin de la bibliothèque dynamique du même nom, toujours la même, durant toute l'exécution du programme.
C'est pour les autres cas qu'il convient de charger manuellement les bibliothèques dynamiques. Quand tu ne sais pas à l'avance de quelle bibliothèque dynamique tu vas avoir besoin. Pour un lot de plug-ins, par exemple. Ou pour pouvoir décharger la bibliothèque dynamique après usage. Le genre de trucs qui est facilité par des bibliothèques dynamiques respectant des conventions précises, par exemple les composants COM.
Comme je le disais avant (mais à vérifier parce que je suis rouillé sur le sujet :oops:) c'est ce manifeste qui est la différence :mrgreen:Citation:
Envoyé par Obsidian
1) bibliothèque dynamique : tu ignores ou tu ne crées pas ce manifeste, mais tu as une .dll. C'est la programmation classique avec LoadLibrary/ FindResource/ FreeLibrary/ ... (<- **)
2) "shared library" : tu linkes statiquement ton exécutable avec ce manifeste mais pas avec la .dll. Donc tu programmes comme "en static" (tu accèdes directement à ta DLL sans la surcouche **). Mais tu es obligé d'avoir l'exécutable + DLL pour que ton exécutable fonctionne.
Par contre bibliothèque d'importation ("import library") je ne me prononce pas sur qu'est que c'est. En lisant le MSDN LIB Reference, ce n'est pas clair :koi: :koi:
Le seul truc sûr, ce sont tout ce qui existe depuis au moins 25 ans : .lib/ .a, .dll/ .so, le manifeste, static/ dynamic/ shared (Windows seulement)
Je suis d'accord. :)Citation:
Envoyé par Obsidian
Pour les bibliothèques statiques, c'est "libtest.a", test étant le nom de la bibliothèque.Citation:
Envoyé par Obsidian
Quand à la bibliothèque d'importation, c'est plutôt : "libtest.dll.a", toujours avec "test comme nom.
D'ailleurs, dans "C:\Msys64\ucrt64\lib" sous Windows, je ne vois que des bibliothèques se terminant par :
:fleche: ".o", je suppose des objets.
:fleche: ".a" pour les bibliothèques statiques.
:fleche: "ddl.a" pour les bibliothèques d'importations (il y en a très peu).
Mais pas de ".lib". En fait, je ne connais pas ce suffixe.
On trouve cela, peut-être, sous MSVC, mais ce ne sont pas des bibliothèques statiques.
Pourquoi ? Car elles sont accompagnés d'une ".dll".
Je suis d'accord. :)Citation:
Envoyé par Obsidian
Le manifest en question ("test.dll.a") ne contient aucune fonctions. Elles sont toutes dans "test.dll".
Par contre, si tu ajoutes une nouvelle fonction, tu devras refaire une édition des liens du programme qui utilise ce manifest.
alors que si tu viens à simplement modifier une fonction déjà existante, tu n'es pas obligé de refaire une édition des liens.
Je n'avais pas pensé au fait que ces bibliothèques peuvent être, comme tu dis, commerciale.Citation:
Envoyé par Obsidian
D'où l'intérêt de les externaliser et non de les inclures dans un programme.
Surtout si cette bibliothèque est utilisée à plusieurs reprises dans différents programmes.
Désolé, mais je ne sais pas de quoi tu parles.Citation:
Envoyé par Obsidian
C'est un usage que je ne connais pas. Choisir sa bibliothèque au moment du traitement ??? Bizarre comme façon de faire.Citation:
Envoyé par Medinoc
En tout cas, je n'en ai pas l'usage.
@ Foetus : une "shared library" sous linux est l'équivalent d'une "dynamic library" sous windows.
Sous linux, c'est fichier se terminant par ".so", alors que sous windows, c'est ".dll".
Je pense qu'au niveau vocabulaire, quand on parle de bibliothèque d'importation, on fait référence à ".dll.a".
Et non à la bibliothèque dynamique, qui est la ".dll". Sous linux, ce la se nomme la bibliothèque partagée (shared library).
L'équivalent des fonctions windows sous linux sont :
:fleche: "loadlibrary()" : "dlopen()".
:fleche: "GetProcAddress()" : "dlsym()".
:fleche: "FreeLibrary()" : "dlclose()".
:fleche: "GetLastError()" : "dlerror()".
Sinon, c'est le même la mécanisme entre windows et linux.
C'est ce que j'ai compris.
Moi aussi, mais ça pourrait pas être du au format utilisé sous Windows pour stocker le code objet ? (ex: COFF vs ELF)Citation:
Pourquoi cette particularité ? Je l'ignore
Tu me prêtes des écrits qui ne sont pas les miens mais ce n'est pas bien grave :lol:. L'important est que ces discussions fassent avancer les connaissances de chacun ;).
Citation:
Envoyé par Artemus24
Les bibliothèques d'importation sont un type particulier de bibliothèques statiques. C'est pour ça que dans MSYS, les deux ont des noms qui finissent par "-.a" (d'ailleurs, le "-.dll-" intercalaire n'était pas là dans les années 2000). Et c'est pour ça que MSVC utilise ".lib" pour les deux.Citation:
Envoyé par Artemus24
C'est utilisé par exemple dans les lecteurs multimédia, où ajouter de nouveaux codecs consiste à ajouter de nouvelles DLL, ainsi que la configuration indiquant au programme lecteur dans quelle DLL se trouve le codec pour tel ou tel format.Citation:
C'est un usage que je ne connais pas. Choisir sa bibliothèque au moment du traitement ??? Bizarre comme façon de faire.
En tout cas, je n'en ai pas l'usage.
Vu que tu n'en as pas l'usage, le plus simple pour toi est de lier simplement ton programme à la bibliothèque statique d'importation, et la bibliothèque dynamique sera liée pour toi sans que tu aies à te soucier de ce qui se passe sous le capot.
D'accord cela ne s'appelle pas *shared library*, c'est peut-être un vieux terme ou je-ne-sais-quoi :aie:Citation:
Envoyé par Artemus24
Mais lorsque tu utilises 1 .dll sous Windows, tu as bien 2 types d'édition de liens : l'explicite et l'implicite.
Et dans la méthode implicite, tu as bien un .lib qui doit être le manifeste.
Link an executable to a DLL, MSDN en anglais
Bonjour,
Pour pouvoir appeler les fonctions d'une DLL (dont on n'a pas les sources en général), il faut un fichier d'en-tête qui décrive les noms et chemins aux fonctions de la DLL et éventuellement quelques constantes et structures. Des noms d'usages qu'utilisera l'application sont également présents. En général, ils s'inspirent des noms internes à la DLL, mais ce n'est pas une obligation.
Pourquoi les fonctions (noms et signatures) ne sont pas découvertes automatiquement ? Il y a plusieurs raisons :
- Toutes les fonctions d'une DLL n'ont pas nécessairement vocation à être exportées.
- Les noms ainsi récupérés peuvent être inutilisables pratiquement si les sources de la DLL ont été brouillés (par exemple, dans un souci de préservation pour une DLL commerciale)
- Comment une application pourrait anticiper l'usage de fonctions qu'elle ne découvrirait qu'à l'exécution ?
Ce .h ou .hpp est associé à un .c ou .cpp généralement vide. Ils font partie de l'application et servent de pont vers la ou les DLL qui partagent les même jeux de fonctions décrites.
Ne connaissant pas bien le monde UNIX, ceci n'est valable, sauf erreurs :oops:, que pour Windows.
Salutations
Avec la bibliothèque d'importation sous Windows, j'ai bien un ".dll", mais aussi un ".dll.a", mais pas de ".lib".Citation:
Envoyé par Foetus
Je suppose que le ".lib" est en fait le ".dll.a", ce que Gerald3d nomme le manifest.
C'est au démarrage de l'exécution que la ".dll" est chargé. Si j'ai bien compris, cela se nomme "liaison implicte".
Aucune référence à "LoadLibrary()" ou "GetProcAddress()".
Avec la bibliothèque dynamique, lors de l'édition des liens, le programme ne connait pas la ".dll".
C'est durant l'exécution du programme que sera décidé quoi prendre comme ".ddl".
D'où le fait d'utiliser "LoadLibrary()" ou "GetProcAddress()". Je pense que c'est cela la "liaison explicite".
Dans les deux cas, la ".dll" est séparée du programme. D'où à l'exécution de préciser où se trouve cette ".dll" en ajoutant le répertoire dans le "PATH".
@ Guesset : dans le cas des bibliothèques dynamiques, il n'est pas nécessaire d'avoir le header (.h ou .hpp").
Il est conseillé d'avoir ce header pour les bibliothèques statiques et d'importations.
Chacun fait comme il veut sa gestion des sources et des headers.
Bonjour,
Doc MS (https://learn.microsoft.com/fr-fr/tr...c-link-library) pour le chargement de DLL au démarrage : "Pour utiliser la liaison dynamique au moment du chargement, fournissez un fichier d’en-tête (.h) et un fichier de bibliothèque d’importation (.lib) lorsque vous compilez et liez l’application... Dans la liaison dynamique au moment du chargement, vous devez lier la bibliothèque d’importation SampleDLL.lib qui est créée lors de la génération du projet SampleDLL."
Pour un chargement différé (et éventuellement une libération anticipée), l'association se fait fonction par fonction. La souplesse se paye donc par une écriture sensiblement plus lourde.
Il y a beaucoup d'applications où le démarrage voit défiler une ribambelle de dll dont très peu seront utilisées. Le choix de la simplicité se traduit donc par un démarrage lent.
Salutations
les .a sont les fichiers lib static pour gcc, les .lib pour msvc et clangCitation:
Envoyé par Artemus24
@ Bousk : Un ".a" ne signifie pas nécessairement une bibliothèque statique. Cela dépend de l'outil que tu utilises.
Sous Windows, pour une DLL de nom test, on peut avoir plusieurs formats :
Je suis sous Msys64 (référencé Msys2) et j'utilise MinGW en 64bits.Code:
2
3
4
Si.Citation:
Un ".a" ne signifie pas nécessairement une bibliothèque statique.
Un fichier .a est une archive contenant différents fichiers .o au format ELF sous Linux, COFF/PE sous Windows.
Lors de la compilation en statique, tous les .o de cette archive contenant des symboles utilisés par ton code seront intégrés à l'executable.
Le format .a vient du monde Unix/Linux, Windows utilise .lib+dll pour les bibliothèques statiques.
Avec un compilateur natif Windows, ce sera .lib+dll, avec une toolchain tel que gcc/Mingw porté sous Linux, ça sera .a sauf si tu lui demande du .lib et qu'il est en mesure de le faire (je pense que ça doit être le cas pour gcc qui est capable de créer un exécutable PE pour Windows compilé depuis Linux : cross-compilation)
Un fichier .dll est normalement toujours accompagné d'un fichier .lib pour pouvoir linker la bibliothèque.
Si tu ne l'as pas, MinGW peut le reconstruire, il y a une commande pour ça. Avec MSVC, j'ai cru comprendre qu'on pouvait le faire indirectement.
sous Linux, c'est plus simple, tout est contenu dans le fichier .so (pour une lib dynamique).
Hello,
@Artemus24,
T'as eu ta réponse ? Perso, je trouve que les réponses de @Medinoc et @Guesset sont les réponses attendues (page 2 ou messages #11, #16 et #20).
ne pas oublier la technologie Component Object Model ou COM bref les dll Active X que l'on pouvait également créer avec Visual Basic.Citation:
Envoyé par Artemus24
D'ailleurs jusqu'au développement de .Net Microsoft en faisait un usage intensif dans ses produits comme la suite Office.
Cela permet une parfaite connectivité et interopérabilité entre les applications qui utilisent cette techno.
Je crois qu'avec Delphi il est possible aussi d'appeler une dll COM
@ Gerald3d : oups. Désolé de mettre trompé. J'ai corrigé en mettant le bon auteur, qui est Obsidian.
@Fred1599 : oui et non.
Je ne m'intéresse pas à la bibliothèque statique que je connais.
J'ai peu d'usage de la bibliothèque dynamique que je connais aussi. J'ai eu quelques réponses sur son usage.
Quand à la bibliothèque d'importation, je constate qu'elle n'est pas connnue du tout.
Non, je n'ai pas eu la réponse attendue concernant la bibliothèque d'importation.
Je rappelle que je cherche comme réponse son usage et non comment elle fonctionne.
J'utilise déjà ces trois biliothèques dans mon environnement.
C'est un peu le bordel, et j'aimerai ne pas me tromper dans la conformité de son usage.
J'ai une nette préférence pour la bibliothèque d'importation que je trouve plus souple à l'usage que la bibliothèque dynamique.
Et surtout cela m'évite de redéfinir plusieurs fois les mêmes fonctions.
En résumé, je pense que la bibliothèque dynamique est utilisé dans l'environnement Windows pour justement faire des écrans.
Voire aussi pour modifier ou compléter l'OS Windows sur des aspects systèmes que je ne connais pas.
Quand à la bibliothèque d'importation, je trouve très peu de trace sous Windows.
Je ne parle pas ici de Linux (dans mon cas Debian), car mon sujet s'intéresse bien à l'OS Windows.
J'aimerai comprendre si la bibliothèque d'importation supplante la bibliothèque dynamique comme étant une évolution pour simplifier sa lourdeur.
Pour quelle usage la bibliothèque d'importation à été conçue ?
Je développe en 'C/C++' sous Windows 10 Pro.
Anciennement (en 2010), j'utilisais 'Dev-C++', puis ensuite "MinGW' (en 2017) et maintenant (2026) "Msys2" (Msys64).
L'environnement "MinGW" que j'utilise maintenant, est celui inclue dans "Msys2", en 64 bits bien sûr.
Je ne connais pas les environnements suivants :
:fleche: Visual Studio puisque j'utilise Msys6 (Msys64 contenant MinGW 64 bits).
:fleche: outils MSVC
:fleche: visual basic
:fleche: active X
Pour les écrans Windows, je développe encore en Win32 à partir du livre de Charles Petzold, "1.Programming Windows, Fifth Edition" (1999).
Sinon, j'ai plusieurs livres sur le 'C', le 'C++' ainsi que sur UNIX. Ils sont tous anciens.
En fait, je fais une mise à niveau de mes anciens développements, entre autre passage au 64 bits.
Bah si en fait, tout a était dit.
Ce que tu appelles une bibliothèque d'importation n'est rien de plus qu'une bibliothèque statique qui va faire les LoadLibrary et compagnies de la bibliothèque dynamique. Ce fichier existe parce les conventions d'appel de mingw ne sont pas les mêmes que celle de msvc et c'était probablement plus simple de l'implémenter ainsi plutôt que consommer directement le .dll. Si le fichier est manquant, mingw peut le créer depuis la bibliothèque dynamique.
Et comme le dit @Medinoc, on charge manuellement une bibliothèque lorsque qu'on ne connaît pas à l'avance celle qu'on veut charger. Principalement pour les plugins, mais aussi lorsqu'on veut choisir un backend et qu'il y en a plusieurs de supporter. Souvent le cas pour tout ce qui est bibliothèque graphique avec mesa, opengl, etc. Ou si on veut supporter plusieurs versions d'une bibliothèque avec des fonctions qui peuvent exister ou non selon les versions. Tous ces cas nécessitent un chargement manuel pour s'adapter à l'environnement et que les bibliothèques ne sont pas fournies avec le programme.
Quand utiliser une "bibliothèque d'importation" ? Quand cette souplesse de chargement n'est pas nécessaire, tout simplement. Et par rapport à une statique: quand on ne fournit pas la bibliothèque dynamique, ou qu'on veut pouvoir mettre à jour une partie du programme sans tout mettre à jour l'ensemble ou simplement parce qu'on n'a pas la bibliothèque statique sous la main.
En fait dynamique et shared font référence à la même chose. C'est aussi le nom de l'option pour en produire sur GCC et certains systèmes de build utilisent shared plutôt que dynamique. C'est même le plus fréquent: xmake, cmake et meson pour ceux que je connais.Citation:
Envoyé par foetus
Je pense que ce nom vient à l'origine du fait qu'une bibliothèque dynamique est, au niveau système, partagée entre tous les process qui l'utilise. Les parties code et data ne sont chargés qu'une fois.
Voici un commentaire de WINDOWS à propos des DLL :
Donc une DLL c'est tout sauf "lourd" !!!Citation:
DLLs provide a way to modularize applications so that functionality can be updated and reused more easilly.
They also help reduce memory overhead when several applications use the same functionality at the same time, because although each application gets its own copy of the data, they can share the code.
A un détail près ... et voici l'exemple :
Il y a pas mal d'années (WIN 98) CBUILDER permettait de développer des exe peu encombrants car en arrière plan il y avait une myriade de DLLs.
Mais le problème survenait quand on changeait d'ordinateur non équipé de CBUILDER. Et plouf : il manquait des DLLs !
Donc CBUILDER proposait de compiler des "auto-suffisants", autrement dit d'intégrer dans l'exécutable les parties de code utiles depuis les DLLs.
Ok ! Mais le problème est que le poids de l'exe n'était plus le même : beaucoup plus grand !!!
Tout ça ... avait un coût en terme de stockage sur le disque dur !
Bien sûr, à l'heure actuelle, on dispose de capacités de stockage qui nous permettent de stocker toutes nos erreurs et le reste aussi !
salut Active X n'est pas un environnement de développement c'est une technologie.Citation:
Envoyé par Artemus24
Ça dépend du point de vue. C'est certain qu'au niveau stockage disque, si plusieurs applications l'utilisent, on y gagne. Mais rien n'est moins sûr au niveau mémoire.Citation:
Envoyé par henderson
Il faut savoir qu'une bibliothèque dynamique est une barrière d'optimisation: le compilateur ne pouvant pas savoir ce que fait la dll, il ne peut pas inliner le code, ni optimiser les appels et les retours puisqu'il n'a aucune connaissance du code derrière. Une fonction qui fait simplement le retour d'un membre d'une structure va être très coûteuse: sauvegarde la pile, appel de fonction, dépilement. Si la bibliothèque ne fait pas grand, ces instructions prennent à la fin beaucoup de place pour peu de code. Les .o et les bibliothèques statiques n'ont pas ce problème si on les compile avec LTO (Link Time Optimization), puisque le compilateur peut optimiser tout ça pendant la construction de l’exécutable.
Un autre point important concernant les bibliothèques dynamiques concerne le cycle de vie des objets créées. Si on veut être libre sur l'implémentation, comme ajouter ou supprimer des membres d'une structure sans devoir recompiler les programmes qui utilisent la bibliothèque, il faut que l'appelant n'ait pas connaissance du layout mémoire des classes / structures. Ce qui veut dire fournir un pointeur opaque (on déclare un type sans jamais le décrire, comme std::FILE) et exposer des fonctions de construction et de destruction. Fonction qui vont allouer dynamiquement de la mémoire, perdre en localité et ajouter un overhead sur le temps exécution et la mémoire. L'appelant doit en plus gérer la duré de vie en appelant les fonctions de destruction. Cela est bien plus lourd que des objets alloués sur la pile et libérés automatiquement par le compilateur.
Tout ça pour dire que l'utilisation de dll à un coût caché ou exposé dans les interfaces et que dans des cas extrêmes, utiliser une bibliothèque dynamique donne un exécutable plus gros qu'utiliser l'équivalent statique (sans compter le poids de la dll elle-même).
C'est un compilateur qui génère la dll, donc son code interne peut être optimisé, inliné. On ne pourra effectivement pas le faire sur une dll qui ne nous appartient pas, mais si son développeur a fait correctement le travail .. Et effectivement du code externe ne sera pas inlinable. Ca peut être un inconvénient.Citation:
le compilateur ne pouvant pas savoir ce que fait la dll, il ne peut pas inliner le code, ni optimiser les appels et les retours puisqu'il n'a aucune connaissance du code derrière.
Il est à noter qu'une bibliothèque peut être mise à disposition sans son code source avec la doc de son ABI.
L'usage d'une bibliothèque partagée a des avantages et des inconvénients.
Avantages :
- code non dupliqué ni sur disque, ni en RAM pour usage par plusieurs applications, ou plusieurs instances d'une même application.
- en cas de correction de code embarqué dans une bibliothèque dynamique, sa correction n'est pas à répercuter dans toutes les applis qui l'exploitent, elles ne devront pas être recompilés.
Inconvénient :
En cas de mise à jour majeure d'une bibliothèque, modifiant son ABI, la cohabitation de plusieurs versions de bibliothèques peut être compliqué
Liste probablement non exhaustive.
Bonjour Christophe,
Le code de la DLL peut effectivement être inline au sein de celle-ci, mais cette caractéristique n'est pas exportable. Inline consiste à remplacer les appels d'une fonction par le déploiement de son code source en lieu et place. Or ce dernier n'est pas accessible au compilateur de l'appelant (sinon ce serait une liaison statique). Par ailleurs l'application utilisatrice n'est pas nécessairement écrite dans le même langage, il suffit que son code source intègre l'équivalent du .h de la DLL pour pouvoir l'utiliser.Citation:
Envoyé par Christophe
Salut