appel de dll dynamique

Bonjour à tous,

bon je pose le probleme: je suis en stage et je travaille sous CVI. Le but de mon stage serait de m'affranchir de DLL interface qui gere l'appel à des DLL de traitement.

Mon probleme et que je peux récupérer les E/S sous forme de chaine de caractére les convertir pour l'appel, en gros j'ai tous sauf que la signature du pointeur sur fonction doit etre construite dynamiquement.

Alors je ne sais pas dois-je écrire du code dans du code ou trouvé un autre moyen

je poste le source de mon fichier test je me tiens à dispo pour expliquer plus en détails.

Merci d'avance.

On ne peut pas construire dynamiquement un appel de fonction sans jouer avec de l'assembleur.

Il faut que les fonctions utilisées aient toutes le même prototype (ce que fait tclcl), ou un nombre fini de prototypes différents avec une valeur indiquant lequel utiliser pour telle fonction (ce que fait MFC pour ses Message Maps).

Citation:

---

Envoyé par EnigmuS

Merci,

Donc en gros pour stage c'est un peu la caca lol vu que les Dll appelées ont un nombre different de paramatres et sont de type variable (je connais par contre statiquement via des fichiers les E/S d'une DLL que ce soit le type,le nombre de paramétres...)

La meilleure solution est donc celle déjà implenté ? (une dll interface pour une dll)

<...>

---

Je suis désolé de te dire que tu parles beaucoup mais de choses que tu ne maitrises pas. C'est donc totalement incompréhensible.

Est-ce que tu sais ce qu'est une DLL ?
Est-ce que "appeler une DLL" a un sens pour toi ? Pour moi, il n'en a pas.

Essaye de poser le problème simplement en expliquant calmement l'existant, et le problème à résoudre. Tu donnes l'impression de ne pas avoir compris le problème. En ce qui me concerne, c'est sûr, je n'ai rien compris.

Et je parle bien du problème, et non des éventuelles solutions.Il n'y a pas de solution à un problème mal exposé.

Désolé pour l'énoncé peu clair je reprend :

Un ensemble de .INI décrivent des tests fonctionnels.

Ce logiciel s’appuie sur les DLLs de communication produit développées en amont pour les divers tests de production, notamment lors des tests Fonctionnels.

Les DLLs de communication produit sont décrit dans un des fichiers INI, et une DLL interface, dont les fonctions ont toutes le même prototype, est développée à chaque produit.

Le chargement dynamique de la DLL interface permet alors la communication avec le produit.

Les DLLs de communication développées en VisualC++ respectent aujourd’hui un formalisme définit, limitant le nombre de types de données possibles (chaine de caractères, entier, flottant, et tableaux)

Et moi je dois mettre au point un chargement dynamique de la DLL de
communication à partir d’un fichier de description des fonctions de la DLL.

Mais le probleme est que lorsqu on appel une DLL on la charge et pour appeler la fonction désirée on y affecte un pointeur sur fonction qui nécessite une signature statique or si je m'affranchie des DLL interfaces comment construire la signature du pointeur et l'appel correspondant juste en lisant dans un fichier .INI.

Comme je l'ai dit, tu ne peux.

Il est impossible de construire directement la liste de paramètres d'une fonction en C. Les bibliothèques qui font ce genre de choses le font en assembleur, ou commencent par générer un stub qui lui-même nécessite de l'assembleur ou une compilation dynamique.

Mes connaissances en assembleur se limite à l'ARM7 lol

En tout cas si c'est la seule solution il va bien falloir que je l'implémente, y a-t-il des tutoriaux sur le sujet parce que meme en admettant que je comprenne le principe je suis pas sur d'arriver à le coder en assembleur arf

Pourquoi ne pas continuer à utiliser la DLL d'interface existante, en fait ?

Car c'est lourd apparemment pour le client car on parle de test à une échelle industrielle (Siemens en l'occurence) et si y a des changements ca fait deux fois plus à modifier pour mon entreprise mais je dois avouer que moi aussi la finalité m'échappe un peu.

Mon maitre de stage a vu un prog qui il pense ferait ca. On y rentre des type de parametres dans un certain ordre et il génére un test automatiquement donc ca doit etre pour ca.

Bon attends résumons nous :

Tu as des DLL
tu as une interface générique avec ces DLL

Donc déjà si tu as une interface générique tous les paramètres sont de même type, et dans le même ordre, pour toute les DLLs, non ?

Ensuite tu veux appeler tes fonctions de la DLL pas via une routine d'interface mais directement, c'est ça ?

En fait j'ai une interface générique c'est à dire que toutes les DLL interfaces possédent la même signature (un tableau de chaine en entree, un en sortie et un nombre de parametres) .

Mais chaque DLL interface à un traitement different de conversion (sur le tableau en entrée) et donc d'appel à la DLL qu'ils interfacent.

Et oui on veut les appeler directement en sachant que les paramètres en entrées sont forcement sous la forme de chaine de caractére (donc à convertir).

Et comme je me répète, c'est impossible en C.

Par contre, tu pourrais peut-être générer automatiquement le code source de la DLL d'interface. Il ne resterait alors plus qu'à la compiler.

Citation:

---

Envoyé par EnigmuS

En fait j'ai une interface générique c'est à dire que toutes les DLL interfaces possédent la même signature (un tableau de chaine en entree, un en sortie et un nombre de parametres) .

Mais chaque DLL interface à un traitement different de conversion (sur le tableau en entrée) et donc d'appel à la DLL qu'ils interfacent.

Et oui on veut les appeler directement en sachant que les paramètres en entrées sont forcement sous la forme de chaine de caractére (donc à convertir).

---

Attends je suis plus trop la logique là.. Tu mélanges. Tu parles de DLL d'interface et de DLL.

Ce que je demandais c'est si il y avait un standard pour les DLL appelées... Visiblement non d'après ce que je comprends.

Mais normalement tu devrais pouvoir réduire le nombre de comportements de tes DLL d'interface, non ? Sinon pourquoi faire appel à une DLL d'interface et pas aux fonctions de la DLL directement ?

Si j'ai bien compris, pour chaque DLL de communication, on n'a aucun contrôle sur la signature.
C'est pourquoi chaque DLL est livrée avec une DLL d'interface qui répond aux spécifications de l'application de test.

Seulement, les fournisseurs des DLLs de communications sont des démons de Nog, aussi commencen-t-ils à trouver fatiguant de devoir mettre à jour la DLL d'interface quand ils modifient leur DLL de communication, et ils voudraient pouvoir supprimer les intemédiaires en appelant directement les DLLs de communication dont l'interface n'est pas contrôlable.

Citation:

---

Envoyé par souviron34

Attends je suis plus trop la logique là.. Tu mélanges. Tu parles de DLL d'interface et de DLL.

Ce que je demandais c'est si il y avait un standard pour les DLL appelées... Visiblement non d'après ce que je comprends.

Mais normalement tu devrais pouvoir réduire le nombre de comportements de tes DLL d'interface, non ? Sinon pourquoi faire appel à une DLL d'interface et pas aux fonctions de la DLL directement ?

---

Il n'y pas de standard pour les DLL

On fait appel aux Dll interface car je pense qu'on ne peux pas faire un pointeur de fonctions sur DLL sans connaitre la signature de leur fonction (logique).

Citation:

---

Envoyé par Médinoc

Si j'ai bien compris, pour chaque DLL de communication, on n'a aucun contrôle sur la signature.
C'est pourquoi chaque DLL est livrée avec une DLL d'interface qui répond aux spécifications de l'application de test.

Seulement, les fournisseurs des DLLs de communications sont des démons de Nog, aussi commencen-t-ils à trouver fatiguant de devoir mettre à jour la DLL d'interface quand ils modifient leur DLL de communication, et ils voudraient pouvoir supprimer les intemédiaires en appelant directement les DLLs de communication dont l'interface n'est pas contrôlable.

---

Exactement

À mon avis, tu ne peux contourner cela.
Même pour générer automatiquement la DLL d'interface, la signature des fonctions ne suffira pas: Il y a des choses que seul un humain peut faire...

Citation:

---

Envoyé par EnigmuS

Désolé pour l'énoncé peu clair je reprend :

Un ensemble de .INI décrivent des tests fonctionnels.

---

C'est à dire ? Ce sont des commandes, des paramètres ? On est pas devins...

Citation:

---

Ce logiciel s’appuie sur les DLLs de communication produit développées en amont pour les divers tests de production, notamment lors des tests Fonctionnels.

---

C'est à dire ? Les commandes vont appeler des fonctions de ces DLL ? Tu ne peux pas expliquer les choses simplement, directement ? Mets toi à notre place. On ne sait absolument pas de quoi tu parles, on ne voit rien, on n'est pas dans ton univers...

Citation:

---

Les DLLs de communication produit

---

Aucun sens détecté.

Citation:

---

sont décrit dans un des fichiers INI, et une DLL interface, dont les fonctions ont toutes le même prototype, est développée à chaque produit.

---

N'a aucun sens. Des fonctions différentes ne peuvent pas avoir le même prototype. Le nom est forcément différent. Par contre, elles peuvent avoir le même profil, c'est à dire le même nombre et type de paramètres et le même type retour. Un classique :

Code:

---

int f (int n, char **as)

---

Citation:

---

Le chargement dynamique de la DLL interface permet alors la communication avec le produit.

---

C'est quoi le produit ? Le logiciel à tester ?

Citation:

---

Les DLLs de communication développées en VisualC++ respectent aujourd’hui un formalisme définit, limitant le nombre de types de données possibles (chaine de caractères, entier, flottant, et tableaux)

---

L'interface des fonctions de la DLL est donc connue.

Citation:

---

Et moi je dois mettre au point un chargement dynamique de la DLL de
communication à partir d’un fichier de description des fonctions de la DLL.

---

Le chargement d'une DLL se fait à la demande par une fonction système bien spécifique. Ensuite, il faut définir des pointeurs de fonction et les initialiser en allant chercher l'adresse<des fonctions avec une autre fonction système dont j'ai oublié les noms...

Exemple pour la DLL bien connue "inpout32.dll" :

http://delahaye.emmanuel.free.fr/clib/pio/

Citation:

---

Mais le probleme est que lorsqu on appel une DLL

---

Aucun sens. On appelle une fonction, pas une DLL. On charge une DLL. Il faut être précis avec le vocabulaire, sinon, on ne se fait pas comprendre et on passe pour un clown.

Citation:

---

on la charge et pour appeler la fonction désirée on y affecte un pointeur sur fonction

---

Ah, tu commences à montrer que tu sais de quoi tu parles. Il était temps !

Citation:

---

qui nécessite une signature statique

---

Qu'est-ce qu'une "signature statique" ? Je connais 'prototype'. C'est de ça que tu parles ?

Citation:

---

or si je m'affranchie des DLL interfaces

---

C'est quoi ces DLL interfaces ? A quoi ça sert et pourquoi veux-tu les supprimer ?

Citation:

---

comment construire la signature du pointeur et l'appel correspondant juste en lisant dans un fichier .INI.

---

Tu veux faire du dynamique de dynamique ? Je crois que tu en demandes un peu trop.

Je crois que je commence à comprendre. Les DLL interfaces sont là justement pour 'normaliser' les interfaces des fonctions des DLL de communication qui peuvent être diverses. Pour une raison que j'ignore, tu veux supprimer ces interfaces et les remplacer par une génération d'appel dynamique crée à l'exécution à partir de données contenu dans un fichier de commande. C'est de la haute voltige et le résultat ne sera absolument pas portable.

Qu'est-ce qui ne va pas avec les DLL d'interfaces ? Pour moi, c'était plutôt de la bonne conception, 100% dynamique, donc extrêmement souple et programmable par fichier de commande.

Emmanuel, tu as loupé pas mal de choses (EDIT) mais ton dernier paragraphe résume bien.

Le sujet a été clarifié depuis, notamment dans mes derniers posts.
Y compris la raison de cette tentative de changement de méthode.

Citation:

---

Envoyé par Médinoc

Et comme je me répète, c'est impossible en C.

Par contre, tu pourrais peut-être générer automatiquement le code source de la DLL d'interface. Il ne resterait alors plus qu'à la compiler.

---

+1

Quoi qu'il en soit, les fournisseurs des DLLs de communication devront modifier quelque chose s'ils changent l'interface de leur DLL de communication.

S'ils sont trop paresseux pour modifier leur DLL d'interface, il faudra au moins qu'ils modifient les fichiers INI qui décrivent les DLLs de communication.

Et ces fichiers INI devront être vraiment très complets, pour décrire la façon dont la DLL de communication doit être appelée.
Si complets qu'à mon avis, modifier la DLL d'interface sera carrément plus simple... :roll: