Discussion :

[Dragnard]

Bonjour,

Voici quelque temps déja que je développe en delphi et je me trouve face a un problème... bizarre et malgré mes recherche je bute dessus :

Je voudrai utiliser une DLL développée en c/cpp, jusque là rien d'exceptionnel.

J'ai trouvé une application qui utilise cette dll et j'obtiens des résultats. (normal)

Mais quand j'utilise la même dll en delphi, les résultats sont complétement différents.

Pourquoi? Y a-t-il une incompatibilité entre delphi et c/cpp?

Merci a ceux qui prendront le temps de m'aider.

[nicolas.dole]

Bonjour,

As-tu utilisé la directive stdcall dans la déclaration des méthodes coté Delphi ?
Cette directive permet de passer les paramètres de façon standard pour les méthodes d'une dll.

[Dragnard]

Oui, j'utilise bien stdcall, voici comment elles sont déclarées:

function dxl_read_word(id : integer; address : integer): integer; stdcall; external 'dynamixel.dll';

J'ai fais un croisé avec les réponse reçus en c/cpp et les réponses reçus en delphi... et je ne trouve aucune cohérence.

Un projet bloqué a cause d'une intolérence de dll.... c'est vexant....
je trouverai la solution.

[ShaiLeTroll]

stdcall ce n'est pas forcément le choix du développeur C, il existe aussi cdecl
tu n'aurais pas un fichier H avec la DLL pour être sûr de la convention d'appel et surtout du langage C et C++ sont subtilement différent !

dxl_read_word, si le nom est cohérent, cela devrait lire un word (16bit) et non un integer (32bit)
int en C c'est 16bit mais int en C++ c'est 32bit
long ing en C c'est 32 bit, long int en C++ c'est 32bit

Et puis c'est écrit dans la documentation : Information of 2 byte can be read on Dynamixel
tout comme "It has outstading portability in each platform since written in C language."

les int du C deviennent des Word en Delphi

[Dragnard]

Merci pour vos réponses !!! à défaut de résoudre mon problème, elles m'ont permis de me poser d'autres questions, et m'ont donné d'autres pistes de recherche.

Effectivement la fonction "dxl_read_word" lit un word plutôt qu'un integer, j'ai pas fait attention...

Mais mon problème reste entier.

Je pensais que mon problème venait de la dll... Je vais plutôt chercher du côté de mes déclarations de la dll.

J'ai le fichier .h de la dll.

Qu'est ce que je dois chercher dedans ? pour vérifier mes déclarations ?

[ShaiLeTroll]

C'est évident, tu dois consider le H et la documentation avec une norme C donc 16 bit par défaut et non C++ qui est 32 bit par défaut !
int => Word n'est qu'une partie !
la convention d'appel est probablement cdecl du C et non stdcall, je ne suis pas assez habitué au C pour être sûr de cela

[Dr.Who]

La plupart du temps oui les dev C préfère utiliser CDECL que STDCALL (plutôt utilisé en C++ et autre, généralisé dans les API windows).

si je puis me permettre aussi, evite de déclarer tes wrapper comme ça :


function nom(param): retour; convention; external 'blabla.dll';

mais plutot comme ceci :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
unit Unit9;
 
interface
 
{$DEFINE TRUC_FU_STDCALL}
{$DEFINE MACHIN_FU_STDCALL}
 
function truc0(p: word): word; {$IFDEF TRUC_FU_STDCALL}stdcall{$ELSE}cdecl{$ENDIF};
function truc1(p: word): word; {$IFDEF TRUC_FU_STDCALL}stdcall{$ELSE}cdecl{$ENDIF};
function truc2(p: word): word; {$IFDEF TRUC_FU_STDCALL}stdcall{$ELSE}cdecl{$ENDIF};
function truc3(p: word): word; {$IFDEF TRUC_FU_STDCALL}stdcall{$ELSE}cdecl{$ENDIF};
 
function machin0(p: word): word; {$IFDEF MACHIN_FU_STDCALL}stdcall{$ELSE}cdecl{$ENDIF};
function machin1(p: word): word; {$IFDEF MACHIN_FU_STDCALL}stdcall{$ELSE}cdecl{$ENDIF};
function machin2(p: word): word; {$IFDEF MACHIN_FU_STDCALL}stdcall{$ELSE}cdecl{$ENDIF};
function machin3(p: word): word; {$IFDEF MACHIN_FU_STDCALL}stdcall{$ELSE}cdecl{$ENDIF};
 
implementation
 
const
  TRUCDLL = 'truc.dll';
  MACHINDLL= 'machin.dll';
 
function truc0; external TRUCDLL;
function truc1; external TRUCDLL;
function truc2; external TRUCDLL;
function truc3; external TRUCDLL;
 
function machin0; external MACHINDLL;
function machin1; external MACHINDLL;
function machin2; external MACHINDLL;
function machin3; external MACHINDLL;
 
end.

[Paul TOTH]

je pensais que c'était plutôt stdcall sous Windows et cdecl sous Linux (ou Mac)...c'est le cas pour OpenGL notamment.

sinon je trouve dommage que Delphi ne propose pas des directives {$STDCALL ON/OFF} ou équivalente pour forcer la convention d'appel d'une série de fonctions.

Code :

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

1
2
3
4
5
6
 
{$IFDEF WINDOWS}
 {$SDTCALL}
{$ELSE}
 {$CDECL}
{$ENDIF}

[Dragnard]

Coucou a vous!!!

Désolé de tarder, je fais des essais avec divers solution... mais le problème reste entier.

Dans le meilleur des cas j'obtiens le même résultat que mon premier soft, soit dans les autres cas... je ne compile même pas.

je vais voir du coté des codes sources de la dll, si je ne peux pas la refaire en delphi.

Merci a vous

[Dr.Who]

tu as la source ? poste la qu'on te dise quoi faire

[Dragnard]

Bonjour a vous tous,

J'ai trouvé un soft qui permet de "convertire" un fichier ".H" en ".pas".
j'ai donc convertis le fichier ".H" de la dll pour pouvoir l'utiliser dans mon soft, mais cela donne le même résultat.

c'est bien stdcall qui est utiliser comme déclaration...

je bute mais ne désespére pas.

Je met en PJ le fichier ".H" si cala peux aider.

Merci de votre aide.

[Paul TOTH]

je serais curieux de voir ta traduction Delphi car il n'y a pas plus simple comme API, du C et des Integer

[Dragnard]

je suis d'accord, ce n'est pas bien compliqué, c'est pour cela que je trouve étrange que mes résultats soient faux....

voici la conversion :

[Paul TOTH]

cette notation me semble erronée

Code :

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

1
2
 
... cdecl  {$IFDEF WIN32} stdcall {$ENDIF}

cela devrait être

Code :

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

1
2
 
...  {$IFDEF WIN32} stdcall {$ELSE} cdecl {$ENDIF}

[ShaiLeTroll]

Pour la convention, il y a explicitement des __stdcall, j'aurais tendance à mettre la même chose en Delphi, et comme le fait remarquer Paul, le générateur s'est un peu planté !

La question sur l'utilisation d'un int du C ou d'un int C++ semble avoir un début de réponse via la directive __cplusplus, si le code est conçu pour être compatible C++ en environnement Win32 (DLL oblige), ça devrait donc être de int 32 bit donc Integer serait approprié !

Maintenant, si le H est commun à différentes plateformes, ça devient plus compliquer car en C++, la taille du int dépend de l'architecture ciblé, on espérer que le H d'un DLL respecte les conventions Win32 !

C'est d'ailleurs pour cela que je préfère utiliser des types Windows (WORD, DWORD...) dans les H ou PAS de mes DLL, puisque de toute façon une DLL c'est uniquement pour Windows autant utilisé une convention commune à plusieurs langages, celle de l'OS !

@Dragnard, As-tu essayé les SmallInt ?
Est-ce mieux pire en SmallInt qu'en Integer ?
As-tu essayé le non signé comme Cardinal ou Word



Cette fonction __dxl_makeword est étrange, deux Word pour un constuire Un ???
Cette API est étrangement conçue, le type int généralisé sans préoccupation me gêne franchement !
C'est typiquement le genre de flou artistique qui me font douter de la rigueur des auteurs !

Code :

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

int __stdcall __dxl_makeword( int lowbyte, int highbyte );

devient

Code :

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

function __dxl_makeword(lowbyte: SmallInt; highbyte: SmallInt ): SmallInt; stdcall;

Perso, je l'aurais déclaré ainsi en C ou C++ pour GARANTIR le typage

Code :

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

unsigned short int __stdcall dxl_makeword(unsigned char lowbyte, unsigned char highbyte );

et ainsi en Delphi

Code :

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

function __dxl_makeword(lowbyte: Byte; highbyte: Byte): Word; stdcall;

[Dragnard]

Bonjour a vous, et bonne fête de fin d'annee.

Pour le probleme de dll... vu que j'ai les codes sources de la dll, je vais la reproduire en delphi, ce sera plus simple... je pense.

merci de votre aide.