Discussion :

[declencher]

Bonjour,

Je développe une application depuis plusieurs années maintenant, et j'avais isolé certaines fonctions dans des dll. Ces librairies sont maintenant passées en open source, et ce sont les retours des développeurs qui me poussent à réfléchir à la question suivante :

Est il possible de créer une structure de dll compatible delphi/C++/VB, et si oui comment faire ?

Je savais depuis longtemps que le type string posait problème, et je vais revoir ça. Mais que faire de mes types de données integer, boolean, word, double, byte et surtout mes record ?

Vous l'aurez compris, mon appli est écrite en delphi, mes premières dll aussi, et des développeurs ne connaissant pas delphi avaient également envie de développer de nouvelles dll et de les partager avec les utilisateurs...

[Paul TOTH]

Bonjour,

Je développe une application depuis plusieurs années maintenant, et j'avais isolé certaines fonctions dans des dll. Ces librairies sont maintenant passées en open source, et ce sont les retours des développeurs qui me poussent à réfléchir à la question suivante :

Est il possible de créer une structure de dll compatible delphi/C++/VB, et si oui comment faire ?

Je savais depuis longtemps que le type string posait problème, et je vais revoir ça. Mais que faire de mes types de données integer, boolean, word, double, byte et surtout mes record ?

Vous l'aurez compris, mon appli est écrite en delphi, mes premières dll aussi, et des développeurs ne connaissant pas delphi avaient également envie de développer de nouvelles dll et de les partager avec les utilisateurs...

si tu utilises des string avec ShareMem, c'est la première chose à changer.

pour ce qui est des Byte, Word, Integer, Double ils existent en C++/VB

Boolean n'existe pas en tant que tel, mais en fait c'est un Byte = 0 ou 1

les record existent également, tant qu'ils contiennent des types connus ce n'est pas un problème.

[ShaiLeTroll]

Le mieux, c'est de faire comme les API Windows et donc d'utiliser les types Windows au lieu des types Delphi, tu pourras plus facilement communiquer avec les autres développeurs si déjà vous êtes d'accord sur les types !

Pour les record, attention à l'alignement sur les registres (voir packed et directive associée)

je suppose que ce sont des DLL utilisées via le mot clé external ou via le couple LoadLibrary\GetProcAddress, on va dire DLL stdcall

Tu peux encaspuler tes DLL stdcall par des DLL COM
Cela présente l'avantage d'uniformiser les types (puisque limiter au type autorisé par Automation), cela permet de faciliter l'utilisation, cela inclu une bibliothèque de type qu'il facile à intégrer avec C++Borland ou Visual Studio !

En plus, cela facilite l'utilisation en C# ou VB.Net si tu respecte la convention safecall !
Car un Objet COM proprement écrit peut être utilisé comme une Assembly (ben oui, faut pas trop leur compliquer la vie aux habitués du Garbage Collector)

Car en C++, certains vont réclamer des fichiers .lib (parce qu'il ne savent pas les générer eux même depuis la DLL) et les headers (parce qu'ils n'ont pas envie de traduire tes éventuelles headers en delphi)

On a l'impression que tu souhaites ouvrir ton application à l'ajout de Plug-In extérieur ?

[guillemouze]

Attention aussi aux enums qui sont stockés sur 1, 2, 3, ou 4 octets selon le nombre l'elements qu'ils contiennent.
J'avais deja eu un probleme avec ca pour utiliser une fonction de windows dont je n'avais pas l'entete en delphi, et j'ai du rajouter une directive de compilation, {$Z4} il me semble, pour que les enums soient sur 4 octets

[declencher]

Je ne m'attendais pas à des réponses aussi intéressante ! Malheureusement vous m'avez perdu...

Auriez vous des tuto qui présente la compatibilité entre les formats de données ? C'est quoi cette histoire de "packed" ? Il y a une liste de directives prédéfinies à utiliser pour améliorer la compatibilité entre les langages ?

Cette histoire de dll COM m'intéresse beaucoup, je ne pensais pas que le compatibilité pouvait aller aussi loin. Je vais tenter des recherches. Des lectures à me conseiller ?

Si j'ai bien compris je dois virer les string, remplacer les boolean par des Byte pour éviter toute incompréhension avec les développeurs, et je vais lire le lien sur le "safecall".

Merci pour ces premières infos !

Je confirme, j'ouvre mon soft à des plugins. Pour la petite histoire, je bosse dessus lorsque j'ai le temps, depuis plusieurs années. J'avais utilisé des plugins développé en delphi. Le but des premiers plugin est de rendre le soft compatible avec plusieurs hardware car selon les fabricants le protocole change. Ayant moins de temps qu'avant, je ne pouvais plus bosser sur des protocole que je ne pouvais pas tester moi même. j'ai partagé tous les plugins existant en les mettant en open source, mais il y a des gens doués qui développe dans d'autres langage, et en plus ils rendraient service à de nombreux utilisateurs.

[Paul TOTH]

Je ne m'attendais pas à des réponses aussi intéressante ! Malheureusement vous m'avez perdu...

Auriez vous des tuto qui présente la compatibilité entre les formats de données ? C'est quoi cette histoire de "packed" ? Il y a une liste de directives prédéfinies à utiliser pour améliorer la compatibilité entre les langages ?

Cette histoire de dll COM m'intéresse beaucoup, je ne pensais pas que le compatibilité pouvait aller aussi loin. Je vais tenter des recherches. Des lectures à me conseiller ?

Si j'ai bien compris je dois virer les string, remplacer les boolean par des Byte pour éviter toute incompréhension avec les développeurs, et je vais lire le lien sur le "safecall".

Merci pour ces premières infos !

Je confirme, j'ouvre mon soft à des plugins. Pour la petite histoire, je bosse dessus lorsque j'ai le temps, depuis plusieurs années. J'avais utilisé des plugins développé en delphi. Le but des premiers plugin est de rendre le soft compatible avec plusieurs hardware car selon les fabricants le protocole change. Ayant moins de temps qu'avant, je ne pouvais plus bosser sur des protocole que je ne pouvais pas tester moi même. j'ai partagé tous les plugins existant en les mettant en open source, mais il y a des gens doués qui développe dans d'autres langage, et en plus ils rendraient service à de nombreux utilisateurs.

tu proposes donc aux gens de développeur leurs propres DLL Plugin ? je ne savais pas que VB permettait de faire des DLL.

Tu peux déjà lire en ligne le chapitre sur les DLL du livre Delphi 7 Studio.

Pour COM c'est une idée, mais ça oblige aux développeurs de connaitre COM...alors qu'une API de base sera plus simple à mettre en oeuvre...après tout dépend de la complexité de cette API.

Ensuite je te recommande de documenter ton API par des termes génériques, ou en définissant clairement ceux du Pascal, les programmeurs des autres langages s'y retrouveront.

Code :

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

1
2
3
4
5
6
7
 
Byte : 8 bits non signé
Word: 16 bits non signé
Integer : 32 bits signé
Cardinal : 32 bits non signé
etc...
Record : définition de structure

packed indique simplement qu'il n'y a pas d'alignement des champs d'un record (alignement qui affecte les temps d'accès aux données).

exemple, compare les SizeOf() de ces records

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
 
type
  TRecord1 = record
     b : Byte;
     i : Integer;
  end;
 
  TRecord2 = packed record
    b : Byte;
    i : Integer;
  end;
 
  TRecord3 = packed record
    b : Byte;
    pad : array[1..3] of Byte;
    i : Integer;
  end;

[declencher]

Exact, ils développent leur propre plugin, et ensuite ils partagent avec d'autres utilisateurs s'ils le souhaitent. Ils peuvent s'insipirer de mes plugins qui sont disponibles sur Google Code depuis un moment maintenant.

La structure des plugins est vraiment très simple, mais j'aimerai la revoir pour aller plus loin (ajouter des plugins pour assurer plus de compatabilité avec les format de fichier par exemple), et attirer l'attention de plus de développeurs. Des volontaires il y en a, mais Delphi n'est pas toujours leur langage... (Je ne sais d'ailleurs pas si VB permet de faire des dll, mais un internaute m'avait contacté pour essayer).

Merci pour le conseil de lecture. J'ai la version papier donc je vais m'y replonger .

Et merci pour les conseils !

[guillemouze]

Quel bon commercial ce paul

[declencher]

On ne peut pas lui en vouloir quand on a sorti une référence pareil

Est ce que quelqu'un peut m'expliquer en quoi la notion d'alignement des données d'un record est importante pour être compatible avec d'autres langages ?

Dis autrement : Dans quel cas on fait du "packed" ?

[Paul TOTH]

On ne peut pas lui en vouloir quand on a sorti une référence pareil

Est ce que quelqu'un peut m'expliquer en quoi la notion d'alignement des données d'un record est importante pour être compatible avec d'autres langages ?

Dis autrement : Dans quel cas on fait du "packed" ?

ça n'a pas d'importance...mais il faut que tu précises l'alignement de tes record pour que les autres développeurs adaptent leurs structures

idem pour la convention d'appel, stdcall est utilisé par Windows, mais rien ne t'oblige à faire de même, faut juste que tu le précises dans la doc.

[guillemouze]

ça n'a pas d'importance...mais il faut que tu précises l'alignement de tes record pour que les autres développeurs adaptent leurs structures

C'est valable pour tous les langages l'alignement ? le C++ fait aussi le non packed ?
Je sais que dès que j'utilise une dll C/C++, je met packed sinon bonjour les degats.

Est ce que quelqu'un peut m'expliquer en quoi la notion d'alignement des données d'un record est importante pour être compatible avec d'autres langages ?

c'est tres simple (si je ne me trompes pas), le compilo essaye d'aligner tes données sur 4 octets si tu ne precise pas packed, sinon il les met a la suite
Si on reprend l'exemple de paul (j'ai mis entre crochet comment il est stocké, en hexa)

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
 
  TRecord1 = record [bb 00 00 00 ii ii ii ii]
     b : Byte; [bb 00 00 00] //on met des 0 pour aller jusqu'a un multiple de 4
     i : Integer; [ii ii ii ii]
  end;
 
  TRecord2 = packed record [bb ii ii ii ii]
    b : Byte; [bb] //on utilise la place strictement necessaire a chaque type
    i : Integer; [ii ii ii ii]
  end;
 
  TRecord3 = packed record [bb 11 22 33 ii ii ii ii]
    b : Byte; [bb]
    pad : array[1..3] of Byte; [11 22 33] //pad est utilisé pour combler manuellement les 3 octets a ajouter pour aligner b & i
    i : Integer; [ii ii ii ii]
  end;

[Paul TOTH]

C'est valable pour tous les langages l'alignement ? le C++ fait aussi le non packed ?
Je sais que dès que j'utilise une dll C/C++, je met packed sinon bonjour les degats.

en C c'est avec des #pragma, mais peu importe, le tout c'est de savoir ce qu'on attend, ensuite c'est au langage de s'adapter

[Montor]

Integer en vb6 est sur 16 bit signé son équivalent c'est le long utilisé aussi comme pointer pour faire des routines Pchar

[declencher]

Si j'ai bien compris, on fait du packed dès qu'il faut s'assurer d'une compatibilité entre les langages, sinon, sauf question de performance, ce n'est pas la peine d'y penser.

Exact ?

[Paul TOTH]

Si j'ai bien compris, on fait du packed dès qu'il faut s'assurer d'une compatibilité entre les langages, sinon, sauf question de performance, ce n'est pas la peine d'y penser.

Exact ?

non, on fait du packed quand on ne veux pas que le compilateur aligne les données

dans mon exemple précédent TRecord1 et TRecord2 sont strictement identiques...pourtant un seul des deux est packed. Le langage externe devra lui aussi jouer sur l'alignement de toute façon, quelque soit ton choix il devra faire le même

[declencher]

Merci pour les infos.