Discussion :

[jimif57]

Bjr,

qqun pourrait-il m'expliquer comment appeler une fonction Pascal developpee avec Delphi a partir d'un pgm Visual C++ ?

Merci d'avance
jimif@free.fr

[Médinoc]

Je dirais comme n'importe quelle autre fonction contenue dans une DLL: Utiliser P/Invoke, comme en C#.

[bacelar]

Delphi .NET ?

Sinon il faudrait trouver les outils Delphi pour générer des ;h et des .lib.

Sinon utiliser "LoadLibrary" et "GetProcAddress" et c'est le début des galères.

[Médinoc]

Ah oui jimif57, j'ai supposé que tu programmais en .Net (C++/CLI ou Managed C++) et non en natif, parce que tu as posté ici. Si ce n'est pas le cas, de simples LoadLibrary()+GetProcAddress() devront faire l'affaire...

[jimif57]

Merci de vos reponses, j'ai trouve LoadLibrary et GetProcAdress dans la doc, mais pas encore testé.
Et pour passer des parametres, je fais comment ?
Puis je sinon utiliser des variables globales visibles depuis le Pascal ?

[Médinoc]

J'ignore si on peut utiliser des variables globales avec GetProcAddress(). La méthode conseillée, c'est de faire un getter et un setter.

Pour les paramètres, il te faut un pointeur de fonction du bon type. Typiquement, pour une fonction qui ajoute deux ints:

Code :

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

1
2
3
4
5
6
7
typedef int (__stdcall * ADDPROC)(int, int);
 
...
 
HMODULE hMod = LoadLibrary( ... )
ADDPROC addProc = reinterpret_cast<ADDPROC>(GetProcAddress(hMod, "Add"));
int resultat = addProc(2, 2);

(sans compter la gestion d'erreurs, bien sûr).

[bacelar]

Médinoc, le problème n'est pas en quoi jimif57 développe mais en quoi est développée la fonction appelé.
De plus, les conventions d'appel de la fonction Pascal ne sont pas forcément celles des API Win32 implémentées en C avec convention stdcall.
J'ai bien dit que s'était le début des emmerdes, non ?
On est en C++, on a les coudés franches pour faire notre tambouille pour les conventions d'appel mais comme dirait une araignée : "un grand pouvoir entraine une grande responsabilité".
Donc, il faut prendre la peine de regarder s'il existe dans l'environnement Pascal s'il y a de quoi générer des .h et des .lib.

Si on ne dispose pas de ces outils, il faudra voir avec "Depends" comment est exportée la fonction Pascal. Son nom d'exportation peux indiquer ces conventions d'appel s'il respecte les usages de Microsoft (qui ne sont pas des normes).

[Médinoc]

Le raccourci que tu sembles me reprocher d'avoir pris, c'est que la convention d'appel recommandée pour les DLLs (__stdcall) est justement la convention d'appel pascal... Il y a encode des #define PASCAL __stdcall dans les headers Windows...

Quand aux informations de convention d'appel dans le nom, en fait, Microsoft recommande de ne pas les mettre dans les DLLs. Mais comme un programmeur C ou C++ doit connaître le format (relativement simple) des fichiers .def pour faire ça, beaucoup de gens se contentent d'un __declspec(dllexport) et c'est le nom C (voire pire, C++) décoré qui est exporté...

[bacelar]

"c'est que la convention d'appel recommandée pour les DLLs (__stdcall) est justement la convention d'appel pascal"
Oui pour la gestion de la mémoire (qui désalloue la pile), et non pour l'ordre de l'empilement des paramètres dans la pile.
C'est le bordel, c'est pas de ma faute.

En plus je ne sais pas comment Delphi exporte les fonctions Pascal (vu que c'est du Delphi) et "Depends" permettra d'avoir des informations sur le type d'exportation donc sur les conventions d'appel.
Mais je souligne la nécessité de rechercher les outils adhoc Delphi avant d'entrer dans cette galère.

J'ai pas compris le dernier paragraphe de la réponse de Médinoc.
Il ne faut pas d'informations de convention d'appel dans l'exportation des fonctions mais il faut connaître le format .def ? Def c'est pour le linker C/C++, il spécifie les conventions et on a un "problème" avec une fonction Delphi/Pascal, il est où le lien.
__declspec(dllexport) fait autant qu'un .def mais en beaucoup plus simple à utiliser. S'il est mal utilisé, ce n'est pas de sa faute mais ses utilisateurs, qui, de toute façon auraient merdés le fichier .def.

En fin de compte, la fonction est-elle exporté dans une dll?
"Depend" donne quoi comme nom à la fonction après exportation dans une dll ?

[Médinoc]

Pour le dernier paragraphe, je parlais des développements en C ou C++ (pour simplifier, on va dire en C).

Si l'on utilise bètement __declspec(dllexport) dans un développement C, la DLL exportera la fonction sous son nom décoré façon C (en __stdcall si le programmeur a bien fait les choses).
Mais s'il écrit un fichier .def, il a la possibilité d'exporter la fonction sous n'importe quel autre nom, y compris son nom non-décoré. C'est cette option qui est préconisée par Microsoft, et c'est même obligatoire si tu veux créer un composant COM, car les bibliothèques Windows cherchent les fonctions sous leur nom non-décoré dans les DLLs (en théorie. En pratique, Windows est peut-être plus permissif).
D'ailleurs, si tu ouvres une DLL Windows dans depends.exe, tu verras que ses fonctions C sont exportées sans leur décoration...

Après, j'ignore comment sont faites les DLLs pascal, ni quel degré de liberté les compilos/linkers pascal laissent aux développeurs, mais je suppose que par défaut, la même convention est suivie... Mais je peux confondre avec VB. De toute façon, personnellement, quand je veux une DLL compatible multi-langage, j'en fais un composant COM.