Pointeurs de fonction un peu originaux

Bonjour,

Voici mon probleme. Je voudrais que mon programme principal scan un repertoire et y cherche toutes les dll presentes. Une fois ceci fait, je voudrais qu'il appelle un point d'entree de chacune de ces dll qui soit toujours le meme, et que lors de cet appel, les dll retournent un tableau de pointeurs de fonctions...

Est-ce possible ?

Dans le cas contraire je voudrais savoir comment faire pour connaitre tous les points d'entree d'une dll si on n'a pas la lib, ni le .h et du coup instancier un pointeur de fonction sur chacun de ces points d'entree.

Est-ce possible aussi ?

Merci d'avance.

Citation:

---

Est-ce possible ?

---

Il n'y a pas d'impossible, seulement des choses difficiles.

Citation:

---

Dans le cas contraire je voudrais savoir comment faire pour connaitre tous les points d'entree d'une dll si on n'a pas la lib, ni le .h et du coup instancier un pointeur de fonction sur chacun de ces points d'entree.

---

En fait, si tu n'as aucune matière, ça va être difficile , une dll n'a pas de point d'entrée propre mais plusieurs points d'entrée (un par fonction de la dll en fait).

En fait la manière de réaliser ceci dépend fortement du système sur lequel tu travailles.

Je travaille sous Windows. En gros je voudrais avoir un noyeau qui sait analyser les commandes tapees sous la console, puis suivant celles-ci, il les redistribue aux differentes dll qui savent les gerer.

Une autre solution serait peut etre de passer a chaque dll la commande, via un meme point d'entree et ensuite, seule celle sachant la traiter s'en charge...

Je pense que tu devrais te rediriger vers le forum developpement windows parce que comme je te l'ai dis, c'est spécifique à une platteforme.

Pour ton cas, juste comme ça, c'est analyse lexicale puis appel de fonction dans les dll, ça ne pose aucun souci !

Citation:

---

Envoyé par PRomu@ld

Pour ton cas, juste comme ça, c'est analyse lexicale puis appel de fonction dans les dll, ça ne pose aucun souci !

---

Ben justement je vois pas trop comment faire cela, j'aurais plus tendance a envoyer la commande a chaque dll qui du coup se tape l'analyse lexicale. Car dans le cas contraire, suivant le resultat de l'analyse il faut que je sache quel point d'entree de quelle dll appeler, or comme le noyeau ne sait pas combien il y aura de dll lancees, ni combien de points d'entree chacun aura, ben du coup c'est un peu galere non ?

Non, le plus "galère" sera pour l'appel lui-même: Tu ne peux pas faire d'appel dynamique de fonctions sans assembleur (ou sans une bibliothèque trifouillant en assembleur), car tu n'as pas de contrôle de la pile.

Résultat, à moins d'avoir des fonctions prévues pour (va_list, ou bien paramètres type "main", comme sous tclcl) tu ne pourras pas faire grand-chose pour les appeler...

SI tu étais sous UNIX, tu aurais les fonction dlsym et compagnie, ça se fait tout seul, il suffit de savoir le nom de la fonction à appler. Mais comme tu es sous windows, je ne sais pas si ça fonctionne de la même façon, et c'est pour cela que je t'ai conseillé d'aller faire un tour sur le forum developpement windows.

Citation:

---

Envoyé par barthelv

Je travaille sous Windows. En gros je voudrais avoir un noyeau qui sait analyser les commandes tapees sous la console, puis suivant celles-ci, il les redistribue aux differentes dll qui savent les gerer.

Une autre solution serait peut etre de passer a chaque dll la commande, via un meme point d'entree et ensuite, seule celle sachant la traiter s'en charge...

---

Même si, je crois, il existe une commande de Windows qui permet de lister les points d'entrée d'une DLL, tu n'auras aucune information complémentaire concernant

• Son interface (parmamètres d'entrée/sortie, retour)
• Son comportement

Donc, je ne vois pas trop l'intérêt. Si tu n'as pas la doc des DLL (SDK), c'est que tu n'as pas à faire de développement avec. Serait-tu en train de faire des actions illégales ?

Citation:

---

Envoyé par Emmanuel Delahaye

Donc, je ne vois pas trop l'intérêt. Si tu n'as pas la doc des DLL (SDK), c'est que tu n'as pas à faire de développement avec. Serait-tu en train de faire des actions illégales ?

---

Pas du tout, c'est moi qui developpe ces DLLs. Et je n'ai pas besoin de faire un programme pour connaitre les points d'entree d'une dll, il me suffit pour cela d'utiliser Dependency Walker.

Non ce qu'il se passe c'est que je veux faire un truc du style l'utilisateur tape une commande, genre "convert", et moi je veux savoir quelle est la DLL qui sait gerer la commande "convert". Donc mon idee originelle etait que au chargement de mon programme, il liste les DLL presentes dans son repertoire, et que celles-ci lui renvoient un tableau associant un nom de commande comme "convert", a un point d'entree a appeler, d'ou ma question.

Avec le recul, je pense qu'un point d'entree unique pour chaque DLLs devant etre implemente, nomme "run", auquel je file la commande, et qui gere lui meme l'analyse pour savoir s'il sait gerer la commande est beaucoup plus simple a implementer.

C'est un peu ce que fait tclcl pour voir les méthodes tcl implémentées par le coté C++ d'un objet.

Ce que tu souhaites faire ressemble a un mecanisme de plug-in (i.e. une bibliotheque dynamiquement chargee qui apporte de nouvelles fonctionnalites a l'application principale). Dans ce cas, il va te falloir mettre en place un mecanisme d'enregistrement des plug-ins, qui vont devoir offrir une interface standard (ta fonction run() par exemple). Il va egalement falloir creer un protocole d'echange de donnees - via un type abstrait peut-etre. En tout cas, l'application principale ne doit pas connaitre les details de l'implementation du plug-in.

Citation:

---

Envoyé par DaZumba

Ce que tu souhaites faire ressemble a un mecanisme de plug-in (i.e. une bibliotheque dynamiquement chargee qui apporte de nouvelles fonctionnalites a l'application principale). Dans ce cas, il va te falloir mettre en place un mecanisme d'enregistrement des plug-ins, qui vont devoir offrir une interface standard (ta fonction run() par exemple). Il va egalement falloir creer un protocole d'echange de donnees - via un type abstrait peut-etre. En tout cas, l'application principale ne doit pas connaitre les details de l'implementation du plug-in.

---

Oui c'est bien ce vers quoi je pense m'orienter. Merci.