Discussion :

[Artemus24]

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 ?

[gerald3d]

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.

[foetus]

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.

[Artemus24]

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 ?

[gerald3d]

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 :

1. dynamique : l'exécutable doit être accompagné des fichiers des bibliothèques utilisées ;
2. 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.

[foetus]

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

MSDN précise que les bibliothèques d'importation c'est l'outil LIB.exe : LIB Reference en anglais

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)

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-fr

Donc, en résumé il n'y a que deux types de bibliothèque

Techniquement il y a 3 types de bibliothèque sous Windows : 3) "shared libraries"
Je suis rouillé sur cette notion et Google/ IA doit l'expliquer précisément 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.

[Guesset]

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

[Mat.M]

Quand à la bibliothèque dynamique, je trouve cela plutôt lourd pour un usage non pertinent.

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.
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

[Artemus24]

@ 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 :
Visual Studio puisque j'utilise Msys6 (Msys64 contenant MinGW 64 bits).
outils MSVC
visual basic
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.

[jo_link_noir]

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.

D'accord cela ne s'appelle pas *shared library*, c'est peut-être un vieux terme ou je-ne-sais-quoi

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.

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.

[henderson]

Voici un commentaire de WINDOWS à propos des DLL :

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.

Donc une DLL c'est tout sauf "lourd" !!!
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 !

[jo_link_noir]

Donc une DLL c'est tout sauf "lourd" !!!

Ç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.

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).

[Mat.M]

active X

salut Active X n'est pas un environnement de développement c'est une technologie.