Discussion :

[NGeVtC87]

Bonjour,

J'ai programmé un exemple de DLL (A.dll) en C++. J'ai définit une fonction dans cette DLL comme suit

Code :

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

1
2
3
4
 
//Fichier A.h
#define ADLL_API __declspec(dllexport) 
ADLL_API long __cdecl  run(void);

J'appelle la fonction run dans un programme exécutable comme ceci

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
20
21
22
 
HINSTANCE _a;
	_a = LoadLibrary(L"A.dll");
 
	if (_a == NULL)
	{
		std::cout << "DLL not loaded" << std::endl;
		system("pause");
		return 0;
	}
 
 
	// Call to run function in DLL A
	typedef long (*runFunction)();
	runFunction run = (runFunction)GetProcAddress(_a, "run");
	if (!run)
	{
		std::cout << "Function not loaded" << std::endl;
		system("pause");
		return 0;
	}
	run();

Le test que j'effectue pour l'appel de la fonction "run" m’indique qu'elle n'est pas chargé alors que la DLL A.dll est bien chargé.
Si quelqu'un a identifié la source de l'erreur qui ne me permet pas d'appeler la fonction run

Merci

[koala01]

Salut,

Attention, il y a une différence entre le fait de compiler la dll et celui de l'utiliser.

Quand tu compile la dll, tu dois t'assurer que chaque fonction exportée sera précédée de la convention d'appel __declspec(dllexport), alors que quand tu l'utilise, tu devra veiller ce qu'elle soit précédée de la convention d'appel __declspec(dllimport).

Tu as donc deux solutions, l'une étant clairement plus pratique que l'autre

La moins pratique consiste à avoir deux fichiers d'en-tête : un qui serait utilisé pour la compilation, et qui utiliserait __declspec(dllexport), et l'autre qui serait utilisé pour l'utilisation et utiliserait __declspec(dllimport).

Cette idée est "pas mal" tant que l'api de ta dll reste simple et, surtout, tant que tu décide de ne pas en fournir le code source.

Mais elle présente un inconvénient majeur pour le développeur : il doit s'assurer de garder les deux fichiers d'en-tête à jour. Et la loi de Finagle aidant, on peut parier gros sur le fait que, tôt ou tard, il "oublira" de mettre l'un des fichiers à jour

Cela nous mène donc à la solution la plus pratique : faire en sorte que le compilateur choisisse la bonne convention d'appel en fonction des circonstances (qui interviendront dans les options du projet).

Pour ce faire, on utilise généralement le préprocesseur, sous une forme proche de

Code :

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

1
2
3
4
5
#if defined(BUILD_BYDLL)
#    define MYDLL_API __declspec(dllexport)
#else
#    define MYDLL_API __declspec(dllimport)
#endif

Où BUILD_BYDLL représente un symbole (dont tu peux choisir le nom à ta guise) qui devra n'être défini que lorsque tu compile ta dll et où MYDLL_API sera le symbole (dont tu peux aussi choisir le nom) qui sera utilisé pour préciser la convention d'appel pour chaque fonction.

L'idéal étant sans doute de le mettre dans un fichier d'en-tête qu'il te suffira d'inclure dans tous les autres. Cela lui donnerait sans doute la forme de
mydll_api.hpp

Code :

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

1
2
3
4
5
6
7
8
9
10
/* un "include guard classique" */
#ifndef MYDLL_API_HPP_INCLUDED
#define MYDLL_API_HPP_INCLUDED
#if defined(BUILD_MYDLL)
#    define MYDLL_API __declspec(dllexport)
#else
#    define MYDLL_API __declspec(dllimport)
#endif  
 
#endif

Par la suite, tu pourras sans doute souhaiter disposer d'une biliothèque statique, en plus d'une DLL. Le truc, c'est que cette convention d'appel est inutile (dangereuse ) dans ce cas. Il faudrait alors le modifier pour lui donner une forme proche de

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
/* un "include guard classique" */
#ifndef MYDLL_API_HPP_INCLUDED
#define MYDLL_API_HPP_INCLUDED
 
#if defined(SHARED_LIBRARY)
/* si on compile une dll */
 
#    if defined(BUILD_MYDLL)
#        define MYDLL_API __declspec(dllexport)
#    else
#        define MYDLL_API __declspec(dllimport)
#    endif
#else 
/* on compile une bibliothèque statique */
#define MYDLL_API
#endif  
 
#endif

Et le fin du fin sera de rendre ta bibliothèque compatible avec les différents systèmes d'exploitation. Or __declspec est une spécificité propre à windows.

Tu pourrais donc modifier ce fichier une dernière fois pour lui donner une forme (finale) proche de

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
20
21
22
23
24
/* un "include guard classique" */
#ifndef MYDLL_API_HPP_INCLUDED
#define MYDLL_API_HPP_INCLUDED
 
#if defined(WIN32)
/* on est sous windows */
#    if defined(SHARED_LIBRARY)
    /* si on compile une dll */
 
#        if defined(BUILD_MYDLL)
#            define MYDLL_API __declspec(dllexport)
#        else
#            define MYDLL_API __declspec(dllimport)
#        endif
#    else 
    /* on compile une bibliothèque statique */
#    define MYDLL_API
#    endif 
#else
    /* pour tous les autres systèmes d'exploitation*/
    #define MYDLL_API
#endif
 
#endif

Voili voilou ;

[NGeVtC87]

Merci pour ton aide,

J'ai suivi vos instruction en modifiant mon fichier d’entête mais ma fonction n'est toujours pas chargé lors de son appel d'un programme externe. Voila ma modif

Code :

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

1
2
3
4
5
6
7
8
 
#if defined( ADLL_EXPORTS)
	#define ADLL_API __declspec(dllexport) 
#else
	#define ADLL_API __declspec(dllimport) 
#endif
 
ADLL_API long __cdecl  run(void);

La solution qui me permet de pouvoir appeler ma fonction est d'inclure les dossier de mon .lib de ma DLL "A.lib" et l chemin vers mes fichiers d’entête de ma DLL. ce qui donne le programme externe suivant

Code :

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

1
2
3
4
5
6
7
 
# include "A.h"
int _tmain(int argc, _TCHAR* argv[])
{
    // Appel de la fonction de la DLL run
    long ret = run()
}

Cette solution implique de fournir les .lib de ma DLL et le dossier des fichiers header avec la DLL contrairement à la première solution où il faut fournir juste la DLL

Merci

[dalfab]

Bonjour,

En utilisant DependencyWalker on doit pouvoir afficher les noms exacts des points d'entrée dans la DLL.
Pour les fonctions C++, elles sont toujours édulcorées en ajoutant les caractéristiques des paramètres en entrée et le type de retour.
En ajoutant extern "C" on va utiliser un modèle C, et le nom de la fonction devrait être trouvé tel quel (ou avec un préfixe valant '_')

[bacelar]

Cette solution implique de fournir les .lib de ma DLL et le dossier des fichiers header avec la DLL

Ce que devrait faire tout bon fournisseur de librairie externe, ainsi que l’équivalent des .lib pour toutes les chaines de compilations et version de compilateur supportées.
SINON, C'EST DES GUIGNOLS !!!

[koala01]

Sinon, tu peux toujours jouer avec LoadLibrary et GetProcAddress... Mais je te souhaites bonne chance

Au fait, y a pas un truc pour récupérer, depuis la dll, tous les nom de fonctions qu'elle exporte

[NGeVtC87]

Merci pour votre aide et vos suggestions

pour récupérer tous les noms de la DLL je crois qu'on peut lancer DependencyWalker. il donne le nom de la fonction éventuellement l'id associé

Ce que devrait faire tout bon fournisseur de librairie externe, ainsi que l’équivalent des .lib pour toutes les chaines de compilations et version de compilateur supportées.
SINON, C'EST DES GUIGNOLS !!!

Je suis d'accord bacelar mais ça m'arrive de trouver des librairie avec seulement la DLL fourinit et une doc décrivant le prototype des fonctions fournis dans la librairie

[bacelar]

pour récupérer tous les noms de la DLL je crois qu'on peut lancer DependencyWalker

Il y a plein d'outils, méthodes pour générer plus ou moins automatiquement des .lib à partir de .dll:
https://adrianhenke.wordpress.com/20...file-from-dll/

[Médinoc]

Attention, générer un .lib à partir de la DLL est déconseillé.

[NGeVtC87]

Merci pour vos réponses et vos suggestions