utilisation de dll avec diverses compilateurs

Version imprimable

16/10/2002, 23h44
Thylia

utilisation de dll avec diverses compilateurs

Salut,

Je développe actuellement avec C++Builder 6 et je suis confronté à un problème : je voudrais utiliser des dll que mon collègue compile avec le compilateur d'IBM, mais lorsque je fait la bibliothèque d'importation (.LIB) avec l'utilitaire IMPLIB, mon compilateur lors du link n'arrive pas à faire trouver la fonction dans le LIB.
A cela, j'ai trouvé un début de solution qui est de déclarer les fonctions en __stdcall. Mais cette solution n'est pas envisageable avec des fonctions C++ surchargées, le compilateur nous jette.
Alors, ce que je vous demande c'est s'il faut mettre un autre type de conventions devant les fonctions ou s'il y a d'autres solutions.

Merci encore d'avance.
17/10/2002, 00h46
JEG

J'ai le meme probleme avec les dll faites sous visual. C'est comme si implib, m'avait viré le corps de la fonction.
17/10/2002, 09h58
LFE

Jeg, il me semble que c'est le probleme dont on a discute l'autre jour.

Thylia, si tu veux, et que la DLL n'est pas trop grosse, envoie la moi avec le fichier .h.

ou une petite DLL toute simple, avec juste une fonction ou 2 :)

Comme ca on sera 3 a pouvoir regarder au probleme ... et ca me permettra de continuer mon tut sur les DLL :)
17/10/2002, 13h14
haypo

Le plus simple est de recompiler le DLL, non ?

Ok, c'est un peu bourrin, mais des fois on a pas le choix. J'ai essayé de compiler un hello world avec GTK+ 2.0 : après 10 IMPLIB, et pas mal de bidouille, je suis arrivé à terminer la compilation et la liaison ... "Internal GTK Error" : "... or your compiler is not supported" :-/ En gros faudrait que je recompile GTK+2.0 avec BCB6 ... mais je vais devoir modifier un gros bout de code pour ça. J'ai abadonné.

@+ Haypo
17/10/2002, 13h49
JEG

effectivement, mais bon l'interet de la dll est perdu...... et des fois on n'a pas le code source de la dll
17/10/2002, 17h26
Gandalf

Il n'y a pas de solutions...

Les surcharges de fonction sont gérées par les compilo par ce que l'on appelle les décorations, c'est à comme si la fonction toto(int) etait appellée toto_int et la fonction toto(double) toto_double. Evidement ces decorations sont codées, et les compilateurs ne decorent pas tous de la meme maniere...

donc pour pouvoir importer un fontion d'une DLL tu dois indiquer à ton compilo de ne pas la décorer -> stdcall ou extern "C"...

Conséquence, la surcharge est impossible...

Un workaround ? faire la decoration toi-meme

toto_for_int (int);
toto_for_double(double);

C'est pas génial, je sais...
17/10/2002, 23h31
Thylia

La solution de recompiler est impossible car tu vois essayer de compiler les dll avec par exemple Borland, ce serait comme essayer de recompiler un prog VC++ (avec Mfc et toute les autres choses de VC++) avec Gcc.

La solution de refaire les dll avec des fonctions qui s'appelle par exemple :
toto_for_int (int);
toto_for_double(double);
n'a pas d'intérêt car on perte tout les bienfait du C++.

On a pensé avec mon collègue qu'il serait intéressant de fouiller vers la numérotation ordinale car elle est unique. Mais, on a pas le temps de si plonger, on est à la bourre pour un projet et donc si vous pouvez voir ou me dire quelque chose dans cette direction, je vous remercie d'avance.
18/10/2002, 11h43
Gandalf

Pour utiliser la numerotation ordinale il me semble que tu dois charger la DLL explicitement (LoadLibrary) et obtenir l'adresse de chaque methode par un GetProcAdress...

Du coup tu te retrouve avec des pointeurs de fct...

Pour fixer les ordinaux dans la DLL tu dois faire un .DEF...
18/10/2002, 13h11
LFE

Je suis en train de faire l'essai avec fmod, voir comment cela marche et jouer avec leur DLL....
je vous tiens au courant
22/10/2002, 11h57
Thylia

Citation:

Envoyé par Gandalf

Pour utiliser la numerotation ordinale il me semble que tu dois charger la DLL explicitement (LoadLibrary) et obtenir l'adresse de chaque methode par un GetProcAdress...

Du coup tu te retrouve avec des pointeurs de fct...

Pour fixer les ordinaux dans la DLL tu dois faire un .DEF...

Je vois pas pourquoi, il faut faire un fichier .DEF, il suffit juste de savoir le numéro ordinal.
22/10/2002, 15h02
Gandalf

Certes tu peux regarder le numero a l'aide d'outils tel Dependency Walker... Mais qui te garentie que ce numéro ne changera à l'occasion d'une nouvelle compilation de la DLL ?
22/10/2002, 17h23
HRS

moi qui croyait naïvement que l'intérêt de la dll est qu'elle est indépendante du langage qui la crée et indépendante du langage qui
l'utilise

concernant les fonctions surchargées. quand on regarde les API windows,
elles sont pratiquement toutes doublées avec un suffixe A ou W selon
que les caractères font 8 bits ou 16 bits. cela vient surement du fait que le
langage C en permet pas la surcharge, donc les dll non plus.
22/10/2002, 20h08
LeGreg

la dll est effectivement independante du langage,
seul probleme elle n'inclue pas de notion "d'objet"
et de classe
c'est un peu comme pour les fichiers .obj du C que l'on
utilise aussi en C++,
Conclusion les compilateurs sont obliges de feinter
pour permettre d'utiliser des classes a travers des dlls
(ou des .obj) et ca se fait via la decoration de nom (name
mangling) moyen que l'on a trouve de coder des methodes
de classe et la surcharge
dans des fichiers objet d'un langage qui ne supporte
que les fonctions globales et non surchargees...

C'est un bete archaisme, mais d'un autre cote la dll
a ete pense pour un environnement multi langage mais pas objet
pour ca il y a COM, CORBA, COM+, .NET etc..
(qui peuvent utiliser des dlls mais qui deguisent les objets de maniere
standardisee).

LeGreg
22/10/2002, 20h27
Thylia

Donc est ce que la conclusion à en tirer est qu'il est totalement impossible d'utiliser les dll C++ avec différents compilateur ?
22/10/2002, 21h31
LeGreg

si tu restes sous windows
je regarderais du cote de COM.

C'est independant du langage et les objets sont
enregistres aupres du systeme, il y a donc un
petit surcout mais ca peut-etre interessant
pour faire du code objet cross-langage.

LeGreg

Pour ajouter ma pierre à l'édifice :

Effectivement l'utilisation d'un LIB direct est imposible en raison de différence de codage

Par contre, on peut effectivement utiliser un .DEF mais c'est lourd dingue
voir par exemple l'URL suivante pour la méthode :
http://www.xploiter.com/programming/c/borland/3173.html

La technique la plus simple et qui fonctionne toujours (ou presque...) est d'utiliser des méthodes C (extern "C")

Dans le cas d'une classe, voici la technique (je l'ai utilisé pour faire un lien entre une classe C++ et une classe JAVA via l'interface JNI qui est en C)
Code:

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 class MaClass { void MaMethode( long param1, long param2 ); } //-- Méthode qui seront exporté long init_MaClass( void ) {// Construction return ( (long)new MaClass() ); }; void termine_MaClass( long handle ) {// Destruction MaClass *cl= (MaClass *)handle; delete cl; }; void MaClass_MaMethode( long handle, long param1, long param2 ); {// appel de méthode MaClass *cl= (MaClass *)handle; cl->MaMethode( param1, param2 ); } // utilisation dans l'autre DLL... long handle= init_MaClass(); MaClass_MaMethode( handle, 5000, 2 ); termine_MaClass( handle );
Effectivement, c'est un peu long à coder... mais cela marche...

Attention, au allocation mémoire ! Une donnée allouée par une DLL d'un compilateur doit être déssallouer par la même DLL

26/10/2002, 01h24
Thylia

Oui, je sais dejà que c'est possible avec extern "C" ou stdcall, mais pour moi le but, est de conserver les dll's en l'état sans refaire le code (100 000 lignes et + )
Mais merci quand même pour le lien.
26/10/2002, 11h09
PascalV.

Bonjour,

Sinon ce que tu peux faire, c'est charger la DLL manuellement.
Tu fais:

HMODULE handle = LoadLibrary("nom de la dll");
void* adresse de la fct = GetProcAddress(handle, "Nom de la fonction");

Je l'ai fait avec Delphi et VC.
Je ne suis pas sur du LoadLibrary sous Borland mais je pense
que ca existe.

Bonne journée.
Pascal.
28/10/2002, 04h54
LeGreg

Citation:

Envoyé par Thylia

Oui, je sais dejà que c'est possible avec extern "C" ou stdcall, mais pour moi le but, est de conserver les dll's en l'état sans refaire le code (100 000 lignes et + )
Mais merci quand même pour le lien.

euh, tu sais moi j'ai du assurer le passage de nos dlls de VC6 a VC7
conclusion, j'ai passe trois semaines a reecrire le code des interfaces pour que ca compile sous VC6 et que les dlls puissent etre linkees sous VC7, tout en s'assurant que mes modifs n'auraient aucun impact sur nos autres plateformes, ni pour les utilisateurs restes a VC6.. heureusement on n'est pas sense supporter les compilateurs Borland... et les autres plateformes(non windows) n'ont pas (trop) de soucis de compatibilite entre les differentes versions de compilateurs..

Mais c'etait un passage oblige a partir du moment ou certains de nos clients allaient passer sous VC7.

LeGreg
29/10/2002, 01h15
Thylia

Oui, mais même si on réécrivait le code pour que se soit portable, on perdrait obligatoirement les bénéfices du C++ ( plus de surchages, ... ).
02/04/2003, 11h35
DoDoT

Perso j'ai une DLL écrite en C dont j'ai la source, qui m'a été livrée avec une fichier .H, et que j'utilise dans un programme C avec Borland C++ 5. Dans mon fichier .DEF j'ai bien toutes les fonctions de la DLL mais au linkage j'ai l'impression qu'il ne les retrouve pas dans le fichier .LIB... Donc j'ai des Unresolved External... Je dois bidouiller avec des stdcall ou je dois recompiler la DLL ?
02/04/2003, 11h51
Chal

Plusieurs points :
- Des méthodes "extern C" sont exportées "en clair" dans les DLL (sans mangling C++ - spécifique à chaque compilateur) et donc sont exploitables facilements...

- Le fichier include permet de connaitre leur syntaxe (donc c'est plutôt utile !)

- Attention le fichier LIB est par contre spécifique à chaque compilateur donc si la DLL est compilée avec Visual C++ par exemple, le LIB générée n'est pas compatible avec Borland...

- Par contre il est possible de générer un fichier LIB à partir d'une DLL (programme IMPLIB présent dans le répertoire du compilateur Borland)

- les "stdcall" et autres "cdecl" permettent de préciser la convention d'appel des paramètres (L'ordre de passage des paramètres sur la pile), elle doit évidement être la même entre la DLL et le client de la DLL...

Voilà si cela peut depanner...
02/04/2003, 12h15
DoDoT

Bon en fait j'utilise un fichier LIB que j'ai généré mais ca ne marche pas. J'ai remarqué que dans mon .DEF les fonctions étaient en majuscules, contrairement au .H, donc j'ai essayé et hop il les a trouvées dans le .LIB mais maintenant il me dit que la DLL est corrompue... J'ai son code source, donc j'ai essayé de la recompiler mais bien sur ca marche pas, j'en suis la... Et dire que c'est un produit commercial...
03/04/2003, 17h05
DoDoT

J'ai réglé mon probleme c'était bien la DLL qui était corrompue !
23/07/2003, 20h12
DjmSoftware

si l'anglais ne vous effraye pas trop
jettez un coup d'oeil ici
http://www.bcbdev.com/articles/vcdll.htm
et la
http://www.bcbdev.com/articles/bcbdll.htm

Cordialement
13/09/2003, 15h13
adel_dz

salut.

En effet comme il a ete signalé le probleme est 1pb de décortaion de fonctions. Pour simplifie les choses, les methodes des class c++ sont traduite en fonctions c mais comme aucune normalistion sur la traduction des fichier obj n'existeles dll resulatant ne peuvent etre portable. Pour s'en convincre il suffit d'utilser le programme depend.exe outil de chez microsoft (disponible su vs et borland c++) se dernier n'arrive pas reconnaitre les methodes c++.

a+
03/10/2003, 15h48
mat.M

Citation:

Salut,

Je développe actuellement avec C++Builder 6 et je suis confronté à un problème : je voudrais utiliser des dll que mon collègue compile avec le compilateur d'IBM, mais lorsque je fait la bibliothèque d'importation (.LIB) avec l'utilitaire IMPLIB, mon compilateur lors du link n'arrive pas à faire trouver la fonction dans le LIB.
A cela, j'ai trouvé un début de solution qui est de déclarer les fonctions en __stdcall. Mais cette solution n'est pas envisageable avec des fonctions C++ surchargées, le compilateur nous jette.
Alors, ce que je vous demande c'est s'il faut mettre un autre type de conventions devant les fonctions ou s'il y a d'autres solutions.

*Le Greg a tout dit
* construire une DLL Active X COM
*COM c'est justement conçu pour cela
*la DLL pourra être exploitée par n'importe quel environnement qui supporte COM ( Delphi , VB , VC++.....)
Le problème: il faut que la plateforme IBM puisse supporter OLE / COM

Il suffit d'importer la fonction de la dll, le seul problème est qu'il faut connaître le prototype de la fonction, donc pour importer une fonction de type void qui prend un char * et un int en param vous devrez faire comme tel:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #include <iostream> #pragma comment ( lib, "LaLib.lib" ) using namespace std; extern "C" __declspec( dllimport ) void LaFonctionDsDll( char *, int ); int main ( void ) { // vous pouvez utiliser la fonction comme vous le voulez... LaFonctionDsDll( "test", 1 ); return 0; }
Je crois que ce n'est pas trop compliqué... !!!!

Bonne prog, et si vous avez encore des problèmes, envoyer moi un pti MP, ou mail ;)

13/11/2003, 18h48
ShootDX

Salut!

DmXx: il y a un problème de name mangling avec C++ et tu nous sors
un extern "C"!

Sinon, je passais juste par là pour demander s'il existe (ou non...) un "changeur" de libraries statiques MSVC en libraries statiques BCC.
22/03/2004, 14h41
jeab.

J'ai qq difficultés à utiliser des fonctions définies dans un fichier .dll surtout lorsqu'elle prenne des arguments en entrée.

Je souhaite par exemple me servir de la fonction suivante définie comme suit:

extern "C" DllFunc BOOL __cdecl USB_ReadFile(PVOID,DWORD,LPDWORD,ULONG);

Cette fonction prend 4 arguments en entrée et me ressort un booléen. Elle est définie dans un fichier nommé "XtlUsb.dll".

Voici le code développé conformément à l'aide MSDN:

typedef BOOL (WINAPI* USB_ReadFile)(PVOID,DWORD,LPDWORD,ULONG);

USB_ReadFile pUSB_ReadFile;

char chBuffer[66000];
PVOID *lpBuffer = 0;
DWORD nNumberOfBytesToRead = 65536;
LPDWORD lpNumberOfBytesRead = 0;
ULONG Timeout = 5000;

hDLL = LoadLibrary("XtlUsb.dll");
if (hDLL != NULL)
{
pUSB_ReadFile = (USB_ReadFile)GetProcAddress(hDLL,"USB_ReadFile");
if (!pUSB_ReadFile)
{
FreeLibrary(hDLL);
}
else
{
BOOL BResult = TRUE;
BResult = pUSB_ReadFile(lpBuffer,nNumberOfBytesToRead,lpNumberOfBytesRead,Timeout);
}
}

Je n'ai aucune erreur à la compilation. Par contre j'ai une erreur fatale au cours de l'exécution du programme à la ligne suivante:
BResult = pUSB_ReadFile(lpBuffer,nNumberOfBytesToRead,lpNumberOfBytesRead,Timeout);

Auriez-vous une idée sur l'origine de cette erreur?
D'avance merci ;-)
21/10/2004, 16h30
LN84

salut !
J'ai également un problème pour inclure des .dll dans un projet sous Borland C++ version 5. Quel est le code à écrire ou la manip à faire ?
Sinon, j'ai lu que l'on pouvait transformer des .dll en .lib, mais quel est le code exactement ?
Merci d'avance :)

Fuseau horaire GMT +2. Il est actuellement 07h07.