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
[email protected]

[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.