Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
DLL Delphi sous C#
Hello,
j'ai posé une question sur le forum C#...mais comme c'est une DLL Delphi, je fais un lien ici pour ceux qui pourraient répondre
https://www.developpez.net/forums/d2...mport-wchar_t/
La question, c'est comme déclarer en C# une Interface Delphi qui retourne un PChar :/
Merci
LOL, Si tu as une réponse sur l'interopérabilité en C# sur le forum C#, j'en serais surpris, aucun développeur C# ne savait faire la différence en une DLL WinApi, DLL COM et une DLL Assembly, pour eux tout est assembly et ne savent même pas utiliser leur équivalent TDUMP pour reconnaitre ce que contient la DLL soit "dumpbin.exe /exports"
J'utiliserais des WideString pour utiliser le partage de mémoire OLE au lieu du PChar même si en théorie, en lecture seule ça doit être lu
tu as pensé au SafeCall au lieu de StdCall pour les interfaces ?
Car en C# rien de ne précise la convention d'appel
Et en Delphi ça dépend si 32 ou 64bits
En 32, stdcall sera pris en compte, SafeCall ajoute un HRESULT implicite par dessus un stdcall
En 64, stdcall sera ignoré et remplacé par x64, SafeCall étant une convention OLE, normalement c'est un HRESULT implicite par dessus un x64
En 64Bits, côté C#, stdcall sera aussi ignoré au profit de ABI x64
En C# force aussi la cible Platform target forcé en x64 ou x86 puisque tu utilises du code non managé
Regarde ceci https://brokenevent.com/blog/2020-09-02
C'est un peu rugueux à utiliser l'interface comme si c'était une table de pointeur de fonction via GetDelegateForFunctionPointer
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
haha, oui c'est pas faux
intéressant ton lien...comme j'ai répondu à anapurna, je préfèrerais rester sur du PChar pour être compatible C...mais ça semble en effet un peu compliqué à gérer en C#
je vais peut-être faire des nouvelles exportations spécifiques pour C#...
Merci
Je ferais deux DLL
Une DLL proche du C
une DLL COM installé dans le GAC qui fait le Bridge avec la DLL proche du C, juste une DLL passerelle, pas de code métier, juste un proxy
C'est ce que j'ai fait en D7, j'ai encaspulé une DLL type WinAPI dans une DLL COM
Tiens, je note que j'avais tout testé en VBS et puisque ce c'était du COM, toutes les fonctions étaient en safecall
C'est ce que fait le C# qui produit une DLL Assembly et la DLL Interop en plus pour le COM
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Pour OnLog c'est un callBack donc regarde Consuming Unmanaged DLL Functions > Calling a DLL Function > How to: Implement Callback Functions
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Répondre avec citation
Partager