Discussion :

[websurfeur]

Bonjour,

Je regarde depuis quelque jour la façon de faire une DLL et à ma grande suprise je ne trouve pas beaucoup de tutoriaux. Sur les rares tutoriaux que j'ai trouvé on a souvent le droit à :

Code :

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

1
2
3
4
 
#include <windows.h>
BOOL APIENTRY dllMain(...);
export "C" int maFonction();

mais j'ai aussi trouvé :

Code :

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

1
2
3
 
#include "UnHeaderPerso.h"
export maFonction(...);

Quel est la forme à respecter ?

Puis lors de la compilation la dll, le fichier "fichier.lib" ne se crée que si on passe un fichier .def en plus du fichier c ou cpp au compilateur. A moins que je n'ai pas bien compris.

Voici la ligne de commande utilisée :

Code :

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

cl /LD fichier.cpp fichier.def

Pourquoi le fichier .lib ne se crée pas en entrant seulement :

Code :

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

cl /LD fichier.cpp

Mes questions sont les suivantes :
* le fichier .def est-il indispenssable pour créer le fichier .lib ?
* De plus le .lib est-il la seul manière de linker l'exe à la DLL ?

Je m'interesse depuis peu au monde windows et je trouve ça quand même super complexe ! Quand on sait que sous linux avec gcc, il suffit de taper :

Code :

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

gcc fichier.cpp -so fichier.so

pour avoir une librairie linker dynamiquement (dll linux, quoi ! )

Merci d'avance pour vos réponses

[loufoque]

Tu peux aussi simplement faire une DLL avec un .o je crois.

[Matthieu Brucher]

Le .lib sert à un exécutable pour lui indiquer où sont les fonctions à utiliser. A ce niveau, la méthode Windows permet des choses que la méthode GCC ne peut pas.
Le dllMain sert lors d'un chargement dynamique de la bibliothèque, lorsqu'elle n'a pas été liée directement avec l'exécutable, on récupère les adresses des fonctions pour les utiliser, et comme on a beosin de leur nom pour cela, on met un export "C" pour ne plus avoir de décoration dessus, contrairement à la deuxième où l'édition des liens est faite par le compilateur qui connait le nom des fonctions à utiliser.

[Médinoc]

Le fichier .def n'est pas indispensable pour la plupart des bibliothèques, mais il l'est pour certaines qui exportent une fonction qui a toujours le même nom (le .def permet de spécifier que ce nom d'apparaîtra pas dans le .lib et qu'il faudra toujours venir le chercher avec GetProcAddress(); la fonction DllGetVersion() et les fonctions des DLLs COM sont déclarées ainsi).

Le .def permet également de forcer le nom des fonctions. Ainsi, les fonctions de l'API Win32, qui sont en __stdcall, devraient être exportées avec des noms comme "_ShowWindow@8". Mais si tu utilises LoadLibrary() et GetProcAddress(), tu verras que le nom est "ShowWindow", grâce au fichier .def.

Et pour créer une DLL sans fichier .def, on utilise le mot-clé __declspec pour indiquer qu'une fonction est exportée par une DLL. Souvent, le fichier d'en-tête de la DLL contient ceci, afin de pouvoir être utilisé à la fois pour compiler la DLL et pour compiler un programme qui l'utilise:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* Pour l'exportation */
#ifdef BUILDING_NOMDELADLL
#define NOMDELADLL_API __declspec(dllexport)
#else
#define NOMDELADLL_API __declspec(dllimport)
#endif
 
/* Pour le nom de fonction */
#ifndef EXTERN_C
#ifdef __cplusplus
#define EXTERN_C extern "C"
#else
#define EXTERN_C extern
#endif
#endif
 
/* Déclarations de fonctions */
EXTERN_C NOMDELADLL_API void UneFonctionExportee(int);
EXTERN_C NOMDELADLL_API int UneAutreFonctionExportee(char const *);

Quant à la fonction DllMain(), elle est facultative. Mais lorsque la DLL contient des ressources, il faut garder à l'esprit que DllMain() est l'unique moyen sur à 100% pour une DLL de connaître son HINSTANCE/HMODULE. Généralement, lors de l'appel à DllMain(), on enregistre le HMODULE dans une variable globale à la DLL, pour s'en servir par la suite.

[Matthieu Brucher]

A préciser que le NOMDELADLL_API devra être définit à rien pour les compilateurs autres que celui de Microsoft.

[Médinoc]

Euh... Il me semble que sous MinGW, ça marche et c'est utilisé...
J'ai déjà fais des DLLs sous Dev-C++ et le fichier d'en-tête généré par Dev-C++ contenait bien cela (et la DLL fonctionnait)...

[Jean-Marc.Bourguet]

Le .lib sert à un exécutable pour lui indiquer où sont les fonctions à utiliser. A ce niveau, la méthode Windows permet des choses que la méthode GCC ne peut pas.

Tu peux donner des exemples? (En supposant que ce que tu entends par méthode GCC, c'est le format elf et par méthode Windows le format PE, parce que GCC permet en général tout ce que permet le format utilisé).

[Matthieu Brucher]

Par exemple, dans la DLL, on crée une classe avec des méthodes publiques, mais on n'exporte qu'un partie, ça permet de limiter l'interface. Je ne sais pas si GCC le permet et si oui quel est le mot clé à utiliser

[Jean-Marc.Bourguet]

Par exemple, dans la DLL, on crée une classe avec des méthodes publiques, mais on n'exporte qu'un partie, ça permet de limiter l'interface. Je ne sais pas si GCC le permet et si oui quel est le mot clé à utiliser

C'est possible depuis toujours en utilisant les map files de l'éditeur de liens (qui je crois sont plus ou moins l'équivalent des .DEF de Windows). Les versions récentes de gcc permettent de contrôler la visibilité avec des attributs.