Discussion :

[Bousk]

Avec la bibliothèque d'importation sous Windows, j'ai bien un ".dll", mais aussi un ".dll.a", mais pas de ".lib".

les .a sont les fichiers lib static pour gcc, les .lib pour msvc et clang

[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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
test.dll      / code exécutable de la dll                / Windows
test.lib      / Bibliothèque d'importation pour test.dll / MSVC & compatible COFF
libtest.dll.a / Bibliothèque d'importation pour test.dll / MinGW & GCC
libtest.a     / Bibliothèque statique                    / GCC & MinGW

Je suis sous Msys64 (référencé Msys2) et j'utilise MinGW en 64bits.

[Christophe]

Un ".a" ne signifie pas nécessairement une bibliothèque statique.

Si.

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

[fred1599]

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

[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 !

[Mat.M]

active X

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

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

[Christophe]

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.

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

[Guesset]

Bonjour Christophe,

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.

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.

Salut

[henderson]

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

C'est l'équipe qui est derrière le développement de l'exe et de la dll qui est la seule à pouvoir évaluer la pertinence !
On a toujours une bonne raison de développer une dll associée à un exe !

[Guesset]

Bonjour Henderson,

C'est l'équipe qui est derrière le développement de l'exe et de la dll qui est la seule à pouvoir évaluer la pertinence !
On a toujours une bonne raison de développer une dll associée à un exe !

La plupart des DLL ne sont pas créées par la même équipe que celle qui développe l'application, voire la même société. La pertinence dans ce cas est plutôt d'éviter de re-devopper quelque chose qui existe et a fait ses preuves.

L'opportunité de développer une DLL dans le cadre d'une application ne va pas de soi.

Comme évoqué, les DLL présentent un mur d'optimisation que ne rencontrent pas les codes intégrés.
En revanche, elles offrent une modularité appréciable

C'est donc lors de l'analyse organique (définition des grands blocs fonctionnels et de leurs interactions) que peut se dégager un bloc plus autonome (moins de liens) et qui peut avoir un cycle d'évolution différent de celui de l'application utilisatrice. En général, cela demande de redéfinir a minima le bloc pour qu'il soit apte à engendrer une DLL.

Salut

[Mat.M]

@Henderson et Gueset : vous sembler oublier un peu vite que si le système des dll a été développé par Microsoft c'est surtout dans une optique commerciale[
Ce n'est ni plus ni moins que des objets distribués au début de Microsoft et de Windows que ce soit des dll Active X qui utilisent la technologie OLE automation ou des dll "simples"
Avec des dll on peut distribuer des composants afin qu'ils soient utilisés par des entreprises.
Par exemple Business Object de mémoire une entreprise des années 1990 qui a été rachetée par Oracle il me semble c'était une entreprise dont le business consistait à vendre des objets métiers.
Puis après est arrivé Java et ses Applets.
Par exemple si vous développez une application d'entreprise qui a besoin d'un éditeur de plan, d'un module de comptabilité, de finance eh bien vous payez un éditeur pour acheter de tels modules.
C'est pour ça que Microsoft a développé la technologie dot Net par la suite au début des années 2000

[Guesset]

Bonjour Mat.N,

@Henderson et Gueset : vous sembler oublier un peu vite que si le système des dll a été développé par Microsoft c'est surtout dans une optique commerciale...
...Par exemple si vous développez une application d'entreprise qui a besoin d'un éditeur de plan, d'un module de comptabilité, de finance eh bien vous payez un éditeur pour acheter de tels modules.
C'est pour ça que Microsoft a développé la technologie dot Net par la suite au début des années 2000

Je ne vois pas en quoi ce que j'ai écrit laisse penser que la dimension commerciale ait été oubliée. Le rappel systématique que la plupart des DLL sont des produits tiers n'évoque rien d'autre.

Quant à .Net, il n'a rien inventé dans ce domaine, sauf à considérer que le code managé en augmente la fiabilité au prix d'exécutables moins efficients (code intermédiaire).

Salut

[henderson]

http://fr.wikipedia.org/wiki/Dynamic_Link_Library

[Artemus24]

@Henderson : je l'ai déjà lu.
Je recherche des informations complémentaire sur la bibliothèque d'importation (Import Library).
C'est cette question qui est à l'origine de mon sujet.
Je précise que ce n'est pas la bibliothèque dynamique (Dynamic Library) qui m'intéresse, ni la bibliothèque statique (Static Library) sauf par comparaison.

[Médinoc]

Il y a tout une série ici sur les DLLs qui inclut quelques infos sur les bibliothèques d'importation.
Voici les URLs actualisées:

• How were DLL functions exported in 16-bit Windows?
• How were DLL functions imported in 16-bit Windows?
• How are DLL functions exported in 32-bit Windows?
• Exported functions that are really forwarders
• Rethinking the way DLL exports are resolved for 32-bit Windows
• Calling an imported function, the naive way
• How a less naive compiler calls an imported function
• Issues related to forcing a stub to be created for an imported function
• What happens when you get dllimport wrong?
• Names in the import library are decorated for a reason
• The dangers of dllexport (bonus posting from a few years ago)

[henderson]

Peut on me donner un exemple d'usage où la bibliothèque dynamique serait mieux que la bibliothèque d'importation ?

S'il faut juste un exemple, c'est celui de la M.A.O. avec ses synthétiseurs virtuels (VST).
Un VST peut apparaître sur le marché (libre ou payant) bien après le développement de ton séquenceur et il devient alors disponible sous la forme d'une dll sans avoir à tout recompiler !

Néanmoins, je peux aussi apporter un contre exemple où il n'y a plus aucune bibliothèque (ni dll, ni d'importation spécifiques à la génération de signaux... "objets musicaux").
Mais ça ... c'est juste du travail ... beaucoup de travail : mon exe ne fait que 2 Mo (je peux faire du MOOG, KORG, DX7 ...) :

Si ... j'ai quand même une dll ... c'est pour le MIDI : XG (YAMAHA) et c'est juste pour le fun ... je peux m'en abstenir ... puisque je travaille en WAVE !