Discussion :

[kidpaddle2]

Bonjour,

Toujours pour m'informer afin de créer une nouvelle version, carrément propre, de ma prochaine version d'un lecteur audio, j'ai décidé de me renseigner sur la manière de stocker mes fonctions d'affichages (celle que j'ai trouvé par exemple sur internet permettant de créer une région à partir d'un bitmap) ainsi que les différents skins de mon lecteur (des icônes, images etc.).

Je pense que le plus approprié reste la DLL, mais je ne sais que créer une dll simple, permettant de stocker des fonctions, et encore je trouve cela un peu (beaucoup) basique. (est-ce vraiment comme cela ?)
Voici la méthode trouvée :

** [Code::Blocks] New project -> Dynamic Link Library **

Dll.cpp :

Code :

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

1
2
3
4
5
6
#include <math.h>

double __declspec(dllexport) FoisDixPuissance(double nombre, int puissanceDeDix)
{
   return nombre * pow(10,puissanceDeDix);
}

** Build **

Résultat : Une dll, ainsi qu'un .lib ou .a

Puis, dans le programme :

Code :

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

1
2
3
//includes

double __declspec(dllimport) FoisDixPuissance(double nombre, int puissanceDeDix);

Pourriez vous m'éclairer ?

Merci d'avance.

[edit] J'ai trouvé cela, mais comment faire pour que la dll soit mixte ?
Pourriez vous par ailleurs me donner un petit exemple de code source chargeant la dll, et quelques fichiers ? J'ai besoin de quelques exemples...

[Médinoc]

Déjà, ta DLL devrait avoir un fichier d'en-tête mixte. Généralement, on prend ce que donne Visual:

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
#ifdef BUILDING_NOMDELADLL
#define NOMDELADLL_API __declspec(dllexport)
#else
#define NOMDELADLL_API __declspec(dllimport)
#endif

#ifdef __cplusplus
extern "C" 
{
#endif

NOMDELADLL_API double FoisDixPuissance(double nombre, int puissanceDeDix);

#ifdef __cplusplus
}
#endif

Ici, c'est la partie du haut qui nous intéresse, elle définit la macro NOMDELADLL_API.
Pour que le code soit construit correctement, tu dois définir BUILDING_NOMDELADLL dans le projet de la DLL, pour qu'elle soit compilée avec dllexport...



Pour les DLLs avec des ressources, c'est simple : Il te suffit d'ajouter des ressources au projet de la DLL.
Ces ressources doivent ensuite être chargées avec le HMODULE de la DLL (pour un LoadBitmap() par exemple, tu passes le HMODULE dans le paramètre hInstance. Aucun cast n'est nécessaire, il y a un typedef de HMODULE sur HINSTANCE).
Si tu veux charger ces ressources depuis l'EXE, le HMODULE de la DLL peut être obtenu au retour de LoadLibrary() ou en appelant GetModuleHandle("nomdeladll").
Si tu veux les charger depuis la DLL, le meilleur moyen est de définir la fonction DllMain() et de profiter de l'événement DLL_PROCESS_ATTACH pour mémoriser le HMODULE dans une variable globale...

[kidpaddle2]

Je ne suis pas sous Visual, mais je suppose que c'est la même chose pour le reste...

Suis-je obligé de faire les directives de préprocesseur données ? C'est à dire, __declspec(dllexport) n'est-il pas toujours utilisé, ce qui rendrait l'autre inutile ?

Sinon, pour la récupération, je pensais la faire dans le code de l'exécutable, mais savoir le faire pour la dll est bon à savoir

Donc si je récapitule, dans le code source de l'exéctable je dois faire :

1. Code :

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

   HMODULE hmLibrary = LoadLibrary("Libraries\\Library.dll");

2. Code :

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

   HBITMAP hBmp = LoadBitmap(hmLibrary, "monBitmap"); /* Où monBitmap est l'identifiant ressource dans Library.dll */

3. Code :

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

   FreeLibrary(hmLibrary);

Sinon, je n'arrive pas à savoir à quoi sert DllMain... elle est sûrement appelée dès le chargement, mais je trouve cela inutile pour les intéractions avec l'exécutable, à part si, dans une fonction de cette dll je charge un bitmap directement, et à l'appel de la fonction celle ci retourne le bitmap... mais bon.

Q'en penses tu ?

[edit] Je me suis renseigné sur msdn sur la façon que tu m'as donné, et c'est vrai que l'on peut faire comme cela mais est-ce vraiment avantageux ? Après c'est une question de goûts je suppose... je verrais en temps voulu.

Sinon, est-ce qu'une bibliothèque statique observe le même code ? Si non, lequel est-ce ?

[reedit] J'ai beaucoup de questions, je sais :p Dois-je refaire un sujet pour savoir à quoi sert un hook ? C'est une dll, d'accord, mais qu'a-t-elle de spécial ?

[Médinoc]

1. Pour les #define, ça permet d'utiliser le même header pour compiler la DLL et pour l'utiliser.
2. DllMain() sert surtout dans la DLL à initialiser des données globales au process (notamment, des index de Thread-Local Storage) et mémoriser le HMODULE de la DLL.
3. Je ne sais pas si le bitmap est encore valide après le FreeLibrary() : Je n'ai pas testé...
4. Pour une bibliothèque statique, rien de tout cela: Ce sont juste des fonctions.
5. Pour les hook, je ne sais pas exactement, je n'ai pas bossé dessus... Mais certains hooks peuvent être appelés depuis n'importe quel processus, il me semble...

[kidpaddle2]

D'accord. Merci beaucoup pour tout cela. (pour la bibliothèque statique, je parlais efectivement des fonctions)

Et sinon, en ce qui conçerne l'utilisation des fonctions présentes dans la Dll, comment cela marche-t-il ? Je suppose qu'après avoir chargé la dll, on ne peut pas directement les utiliser...

[Médinoc]

Eh bien ça dépend de la façon dont tu utilises la DLL.

Si tu l'utilises en "Load-time dynamic linking" (encore appelée liaison implicite), tu n'as rien à faire, même pas à charger la bibliothèque toi-même : Il te suffit de lier le programme utilisateur à la bibliothèque statique d'importation générée en même temps que la DLL. C'est à cela que servent les déclarations en dllimport.
Quant aux ressources, tu peux récuperer le HMODULE avec GetModuleHandle("NomDeLaDll")


Si tu l'utilises en "Run-time dynamic linking" (encore appelée liaison explicite), tu fais tout toi-même: LoadLibary() pour charger la DLL, et obtenir un pointeur de fonction avec GetProcAddress().
Note: Je conseille de définir un typedef pour ce pointeur de fonction dans le fichier d'en-tête de la DLL :

Code :

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

typedef double (*FOISDIXPUISSANCEPROC)(double nombre, int puissanceDeDix);

[kidpaddle2]

Avec la liaison implicite, on peut tout faire d'après ce que tu dis (récupérer les ressources et les fonctions etc) alors pourquoi utiliser la liaison explicite ?

[Médinoc]

Parce qu'avec la liaison implicite, le programme ne démarre pas sans la DLL. Avec la liaison explicite, on peut vérifier si la DLL existe et autoriser ou non des fonctions...

En fait, la liaison explicite est très bien pour des plug-ins. Les composants COM sont également une forme de liaison explicite, avec un enregistrement de la position des DLLs en plus.

[kidpaddle2]

D'accord. Merci pour tout, je crois que ce topic est désormais résolu