déclarer une classe à exporter dans un fichier .def

Bonjour,
J'ai développé une DLL et je veux l'utiliser dans une deuxième DLL.
Lorsque j'ouvre la première DLL en utilisant Dependency, je vois toutes les classes et les méthodes de ma DLL.
Maintenant je veux que meme en utilisant Dependency, les méthodes et les classes de la première DLL ne seront pas lisibles aux utilisateurs.
Lorsque j'ai cherché dans le net, j'ai trouvé ce lien qui indique qu'on peut utiliser un ficheir .def pour cacher les méthodes à exporter
http://stackoverflow.com/questions/8...nctions-in-dll
J'ai pu utiliser cette méthode pour les fonctions mais j'ai pas trouvé comment je peux déclarer une classe à exporter dans un fichier .def.
Merci pour vos aides

Salut,

Les fonctions (et les classes) qui doivent etre exportées depuis une dll doivent etre déclarées avecl le fameux declspec("dllexport") lors de la compilation.

D'autre part, pour éviter le recours au fichier def lors de l'utilisation, les classes et fonctions importées d'une dll externe doivent être déclarées avec le tout aussi fameux declspec("dllimport").

Le plus facile pour t'assurer que les bonnes fonctions et classe seront effectivement correctement exportées (respectivement importées lors de l'utilisation) est donc de recourir au préprocesseur de manière à les déclarer avec la bonne spécification.

L'exemple minimal serait proche de

Code:

---

1 2 3 4 5

#ifdef BUILD_MYDLL #define MY_DLL_INTERFACE declspecs("dllexport") #else #define MY_DLL_INTERFACE declspecs("dllimport") #endif

---

où MY_DLL_INTERFACE et BUILD_MYDLL seraient des symboles à exclusivement utilisés dans la dll que tu veux créer et où
BUILD_MYDLL serait en outre passé en paramètre lors de la compilation (la ligne de commande de gcc ressemblerait donc à

Code:

---

gcc -DBUILD_MYDLL //la suite

---

;))

La déclaration d'une classe devant être intégralement exportée ressemblerait alors à

Code:

---

1 2 3 4

class MY_DLL_INTERFACE MyClass { // son contenu };

---

Le fait d'avoir forcé l'exportation de la classe permettra à l'outil de création de fichiers def de retrouver l'ensemble des fonctions membres dont ta classe est composée et qui doivent être exportées ;)

NOTA: si les DLL en C++ sont une manière géniale de fournir des plugins à des applications, il faut garder en tête le fait que, contrairement aux DLL's écrites (et compilées) en C, une DLL écrite (et compilée) en C++ ne sera utilisable que par une application C++ ayant été compilée avec la même version du même compilateur et en utilisant les mêmes options que la dll, car l'ABI relative aux dll n'est pas standardisée :P

Merci koala01 pour vos explications. J'ai fait ma DLL comme tu as montré mais mon problème est que lorsque j'utilise le logiciel Dependency je peux voir toutes les méthodes à exporter de ma DLL.
Donc ce que je veux exactement est de cacher les méthodes de ma DLL. même en utilisant Dependency, on ne peut pas voir les méthodes et les classes de cette DLL.

Lorsque j'ai cherché dans l'internet j'ai trouvé qu'on peut les cacher en utilisant un fichier .Def. Mon problème maintenant c'est, y a t il une autre méthode qui permet de crypter ou bien de cacher les méthodes d'une DLL en utilisant Dependency sinon comment je peux déclarer les classes à exporter dans un fichier .def

Euh ... Si je ne me trompe pas, si elles apparaissent dans Dependency, c'est que ces fonctions et classes sont exportées, et il semble donc logique que l'utilisateur puisse les voir.
Si tu veux que l'utilisateur ne voie pas certaines fonctions ou classes, tu as juste à ne pas les exporter (donc pas de __declspec(dllexport)).

Mais comment veux tu utiliser ta dll si tu ne donne pas un moyen à l'utilisateur d'appeler au moins certaines fonctions :question:

A partir du moment où tu veux permettre à un utilisateur d'utiliser ta dll, il faut bien qu'il sache comment le faire, et donc quelle fonction appeler, et comment, non:question:

Autrement, quel serait l'intérêt :question:

Oui ce sont des méthodes exportées.
Comme j'ai mentionné dans la première discussion, j'ai développée deux DLL, une fait appel à la deuxième. la première je la connais et je connais toutes ses méthodes et je veux pas que l'utilisateur sait ce qu'elle contient et la deuxième sera utiliser par l'utilisateur.
Pour moi, Je veux pas que les méthodes de la première DLL soient claires aux utilisateurs. En fait, l'utilisateur connait seulement les méthodes de la deuxième DLL
Le lien suivant explique exactement ce que je veux faire et dans ce lien j'ai trouvé la solution d'utilisation d'un fichier .def

http://stackoverflow.com/questions/8...nctions-in-dll

Merci

Le fait est que tu n'as strictement aucune certitude quant au fait que l'utilisateur accédera aux fonctions de la première dll au travers de celles de la deuxième et qu'il est impossible de dire que les fonctions de la première dll sont exportée pour la deuxième, mais pas pour d'autres binaires: soit une fonction est exportée pour tout binaire qui en a besoin soit elle n'est exportée... pour personne

En outre, je me pose sérieusement la question de l'intérêt que pourrait présenter la chose... à moins d'avoir une besoin de sécurité particulierement élevé, quel serait l'objectif :question:

Au final, je crains que tu n'aies que deux solutions:

Soit tu continue a travailler avec les deux dll et "tant pis", les fonctions exportées par la première le seront y compris pour d'autres binaires (ce qui reste, malgré tout, le but d'une DLL ;))

Soit tu intègre l'intéralité de la première DLL dans la deuxième, en veillant à ne pas en exporter les fonctions

Bonjour,
D'abord, il y a plusieurs DLL qui ont des méthodes exportées et qui ne sont pas visibles aux utilisateurs comme par exemple les DLL de windows.
en deuxième lieu, même si on n'a pas besoin de cette sécurité , puisqu'il y un piste pkoi on ne le voit pas.
Je vous ai donné un lien deux fois, j'espère que vous l'avez vu. EN fait j'en suis sûr qu'il y a plusieurs méthodes puisqu'on trouve les méthodes de plusieurs DLL windows ne sont pas visibles.
et la solution de l'utilisation du fichier .def est l'une des solutions. Pour cette raison j'aime bien s'il y a quelqu'un qui peut m'aider à utiliser le .def pour les classes. car j'ai essayé de faire ça avec des méthodes et ça bien fonctionné mais j'ai pas trouvé une solution avec les classes

ce n'est pas possible (ou c'est tres tres difficile) en C++ a cause de la décoration des méthodes C++.
a priori c'est possible mais costaud.
il faudrait dans un premier temps compiler ta premiere DLL en activant les dllexport pour obtenir une DLL avec des exports
puis obtenir ou générer un fichier .def a partir des exports de cette DLL
enfin, recompiler en retirant les dllexport et rajouter le fichier .def (avec les NONAME comme le dit la doc) pour obtenir une DLL sans les noms des methodes.

Enfin, après ca, bonne chance.

Citation:

---

Envoyé par screetch

puis obtenir ou générer un fichier .def a partir des exports de cette DLL.

---

Merci pour votre réponse mais comment je peux générer un .def à partir de ma DLL.
Merci

A part en VB ou un en utilisant le MFC Dll Wizard, tu n'as pas d'autre choix que de le faire toi-même

Bonjour,
Merci pour votre réponse mais comment je peux ajouter une classe exportées au fichier .def??

Citation:

---

Envoyé par dragonjoker59

tu n'as pas d'autre choix que de le faire toi-même

---

tu n'ajoutes pas une classe, tu ajoutes les méthodes de la classe.
Une classe exportée est juste une classe dont toute les méthodes sont exportées.
Or une méthode de classe est exportée en utilisant un encodage bizarre (la décoration)
Avoir la liste des méthodes a exporter est donc difficile.
D'ou ma solution: tu exportes les méthodes avec _-declspec(dllexport) dans un premier temps
puis tu extraits de la DLL la liste des méthodes a exporter
tu crées un fichier .def qui contient ces méthodes
tu recompiles tout, sans rien exporter, en donnant le fichier .def pour créer les exports.

Citation:

---

Envoyé par screetch

Or une méthode de classe est exportée en utilisant un encodage bizarre (la décoration)
Avoir la liste des méthodes a exporter est donc difficile.

---

Comment je peux faire la décoration(utilisation d'un encodage bizarre). SI je trouve comment les classes et les méthodes seront parus bizarre en utilisant Dependency alors mon problème sera résolu

Citation:

---

Envoyé par screetch

puis tu extraits de la DLL la liste des méthodes a exporter
tu crées un fichier .def qui contient ces méthodes
tu recompiles tout, sans rien exporter, en donnant le fichier .def pour créer les exports.

---

Est ce que le constructeur sera traité comme une méthode de la classe dans le .def.
Car j'ai besoin du constructeur pour que je puisse l'utiliser ailleurs.
Merci

Oui le constructeur est aussi dedans
Tu ne peux pas refaire la décoration, c'est ca le problème. Obtenir le nom des méthodes exportées est ton problème.

pourquoi je peux pas faire la décoration. je veux décrypter les méthodes et les classes. quelle est la méthode qui permet de faire ça.
Merci

le problème n'est pas de decrypter mais d'encrypter
si tu veux exporter MaClasse::MaMethode, il faut trouver son nom une fois le code compilé, pour pouvoir l'exporter.
C'est pour ca que j'ai suggéré ainsi:
compile ta DLL en utilisand __declspec(dllexport)
utilise un outil pour lister les méthodes exportées
celels-ci seront déjà encryptées
recompiles sans les dllexport mais maintenant tu as la liste des méthodes (encryptée) a exporter.

Citation:

---

Envoyé par screetch

utilise un outil pour lister les méthodes exportées
celels-ci seront déjà encryptées

---

Comment les méthodes seront déjà encryptées. J'ai compilé avec VS2008 puis j'ai utilisé le logiciel Dependency, j'ai vu toutes les méthodes telles qu'elles sont. Elles ne sont pas cryptées.

J'aime bien savoir les méthodes de cryptage des méthodes d'une DLL.
Merci

dependency walker est capable de les decrypter, d'autres programmes peuvent le faire aussi.

Salut,

Sinon tu fais une version bibliothèque statique pour ta bibliothèque 'privée' et tu la lies statiquement dans la DLL de la bibliothèque 'publique'...

MAT.