DLL plusieur façons de faire possible ?

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:

---

1 2 3 4

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

---

mais j'ai aussi trouvé :

Code:

---

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:

---

cl /LD fichier.cpp fichier.def

---

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

Code:

---

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:

---

gcc fichier.cpp -so fichier.so

---

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

Merci d'avance pour vos réponses

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

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.

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:

---

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.

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

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

Citation:

---

Envoyé par Miles

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

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

Pour ce qui est des tutos il y a l' MSDN à ne pas hésiter.

Sous VC++ on peut aussi exporter les fonctions de cette façon

Code:

---

extern "C" BOOL WINAPI InitializeLicenceDataDLL();

---

Gabrielly: Avec seulement ça, tu n'exportes rien, là...

Tu dis seulement que la fonction est en __stdcall et possède une interface C (sauf que cette déclaration n'est compilable qu'en C++, car le compilateur C ne comprend pas extern "C").
Pour l'exporter, il faut soit rajouter le __declspec(dllexport), soit mentionner la fonction dans un fichier .def...

Citation:

---

Pour l'exporter, il faut soit rajouter le __declspec(dllexport), soit mentionner la fonction dans un fichier .def...

---

c'est exacte, il faut également la mentionner dans le *.def ;)

Code:

---

InitializeLicenceDataDLL @1

---

Citation:

---

Envoyé par Miles

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.

Ah, une bonne nouvelle donc, je retire ce que j'ai dit ;)