Discussion :

[az0101]

Bonjour, venant du delphi, je lutte pour traduire une librairie écrite en delphi vers le cpp.

Le problème est que les exports ont un nom bizzare, quand je vérifie avec IDA
par exemple au lieu de 'CreateLib' , tel qu' exporté en delphi, je trouve 'CreateLib@0' pour la version exportée en cpp.

dans mon header en c, je déclare:

Code :

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

extern "C" __declspec(dllexport) int __stdcall  CreateLib();

(pour int __stdcall CreateLib().)

en équivalence à

Code :

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

function CreateLib: Integer; stdcall;

en delphi.

quelle est donc la syntaxe obscure a utiliser pour que les noms des exports soient comme ceux générés par le compilo delphi ?

Par ailleur est ce que

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
   return true ;
    switch (fdwReason)
    {
        case DLL_PROCESS_ATTACH:
        {
            return true;
            break;
        }
 
 
        case DLL_PROCESS_DETACH:
        {
            return false;
            break;
        }
    }
}

est efficient pour garder un handle de dll valide ( éviter le déchargement) ? L'équivalent en delphi marche mais l'appel à cette fonction en delphi est totalement différent ( procedure avec 1 seul param correspondant à fdwReason, le rest géré en automatique par le compilo).

[3DArchi]

L'équivalent en delphi marche mais l'appel à cette fonction en delphi est totalement différent ( procedure avec 1 seul param correspondant à fdwReason, le rest géré en automatique par le compilo).

Bonjour et bienvenu,
je te cite le msdn :

When the system calls the DllMain function with any value other than DLL_PROCESS_ATTACH, the return value is ignored.

Tant que ton exécutable tourne, ton handle de DLL devrait rester valide car la DLL n'est pas déchargée ? Ou j'ai loupé quelque chose à ta question ?

Pour les décorations de noms, cf ici.

[az0101]

merci, visiblement il a une contradiction entre la doc de MSDN et celle que j'ai de RAD studio ( qui contient des infos pour le cpp en plus du delphi), à propos du code de retour de dllMain

En fait j'avais mal ciblé le problème.

en cpp si je met les exports en __cdecl, alors les noms sont corrects. Le problème c'est que pour la version du plugin compilé à partir du code cpp, je doit ajouter un

Code :

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

1
2
  asm
  ( "pop %eax" );

dans l'application qui host la dll , sinon elle crashe.
Par contre (et du coup) c'est les plugins compilés à partir du delphi qui crashent dans ce cas. Bref c'est un problème de stdcall / cdecl et de nettoyage des registres cpu... . Sous IDA ca se materialise par un 'pop ebp' présent dans la version delphi et absent dans la version cpp.
Celà pourrait venir du compilo gcc ?

[Médinoc]

Les fonctions sont en __stdcall, ne les fais-donc pas passer pour des fonctions __cdecl.

Si tu veux un nom non-décoré, sous tu dois créer un fichier .def pour indiquer quelles fonctions tu veux exporter non-décorées.

Mais j'ignore comment ça marche sous MinGW...

[az0101]

si tout est en cdecl ( dll venant du delphi, dll venant du cpp , host venant du delphi, alors ca marche). Il semblerait que le stdcall soit moins universel que le cdecl, bizarre, pourtant il me semblait que stdcall était la convention d'appel 'générique' ( compatible entre les differents langage et compilo).

Quoiqu'il en soit cette petite balade dans le monde du cpp fut interessante...

[Médinoc]

stdcall est bien la convention d'appel "générique", et celle préconisée pour les DLLs (et les composants COM).

C'est juste que la décoration des fonctions __stdcall n'est pas tellement générique, elle.

[az0101]

De toute facon utiliser le cdecl dans mon cas est au final plus simple. Avec le stdcall if faudrait faire des test sur les noms d'exports dispo dans la dll, ce qui ralentirait le code.

Celà dit la (non)décoration de nom est vraiment abhérante ! un export stdcall à partir de delphi devrait être le même qu'en c ( sinon ce n'est plus une convention !). Je pense que Borland et CodeGear ont un peu "merdé" la dessus, même si je ne connais pas bien le pourquoi du comment...

[Médinoc]

Avec le stdcall if faudrait faire des test sur les noms d'exports dispo dans la dll, ce qui ralentirait le code.

Huh?!
Comprends pas ce que tu dis, là...

Celà dit la (non)décoration de nom est vraiment abhérante ! un export stdcall à partir de delphi devrait être le même qu'en c ( sinon ce n'est plus une convention !). Je pense que Borland et CodeGear ont un peu "merdé" la dessus, même si je ne connais pas bien le pourquoi du comment...

Si tu mets un fichier .def (du moins sous Visual), tu peux exporter le nom non-décoré, comme recommandé.

[Médinoc]

Tiens, voilà quelques infos là-dessus: http://www.willus.com/mingw/yongweiwu_stdcall.html
Ces infos montrent bien que Visual fait les choses comme il faut quand il y a un fichier .def, et le document montre comment faire avec MinGW pour exporter les fonctions sans décoration.

[az0101]

de toute manière c'était pour un sdk de plugin. En cdecl ca marche donc la c'est bon, c'est releasé, le cpp j'en est rien à foutre c'était juste pour faire un exemple de plugin pour mon application à partir du cpp. ( désolé pour la violence du discour, mais bon...).

Edit:

En fait j'ai la haine parce que ton précédent message me fait comprendre que j'ai changé les conventions d'appel par méconnaissance du cpp. Il y avait moyen d'éviter la décorration...mais là j'ai tout changé dans l'host, c'est à dire que les prototypes de fonctions sont basées sur cdecl maintenant.

( MonTypedeprocédure = fonction():integer ; cdecl; ). car j'utilise un système de chargement dynamique/objet de la dll.

Dans la mesure ou le plug n'est pas plus instable en cdecl qu'en stdcall ca ne fait rien...