Discussion :

[Fbartolo]

Voila, j'ai une DLL que je veux utiliser et qui a été développée en C semble t-il.

je déclare dans mon programme la fonction (de la DLL) comme cela:

Code :

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

1
2
3
4
5
extern  void  conv (struct MessIn *, struct MessOut *,
                    int   (*)(void),                    /* GetSecurity() */
                    int   (*)(void),                    /* GetKey       */
                    int   (*)(char *, int, char *),     /* GetStringFromKeyboard */
                    void  (*)(char *, int, short));     /* pos_display() */

et j'ai rajouté dans le fichier prj.BPR convdll.dll qui est le nom de la dll, ce qui donne:

ALLLIB = $(LIBFILES) import32.lib cw32mt.lib convdll.dll


lors de la compilation et du make j'ai le message:

[LieurErreur] Error processing module F:\PACKAGE\DLL\CONVLL.DLL.

lorsque j'utilise la fonction dump.exe -ee convdll.dll il me sort :
EXPORT ord:0000='conv' donc la fonction est visible ???

HELP!!!!

[Balise [code] & [quote] ajoutées par netah_25 - Merci d'y penser a l'avenir]

[Pylz]

Bonjour,


Je ne connais pas Builder3 (je suis arrivé directement au 5...) mais n'y a-t-il pas de possibilité de passer par un .lib ??

[Fbartolo]

Le pb c'est que je n'ai pas la .LIB ... mais le principe reste le même je crois ??

[Trap D]

Ta Dll a été écrite en C ou en C++, car il y a un problème de décoration des noms en C++, fais un impdef de la Dll pour savoir.

[Pylz]

Tu peux toujours créer le .lib à partir de la dll. Avec IMPLIB.
si les noms ont été décorées il faudra utiliser une des options (je sais plus laquelle... ).

[Fbartolo]

Alors après utilisation de la commande IMPDEF le fichier .def est généré avec:

LIBRARY CONVDLL.DLL

EXPORTS
conv @1

Après avoir changé la librairie DLL par LIB le compilateur me sort maintenant:

[LieurErreur] Unresolved external '_conv' referenced from F:\C3KIT\DLL\TEST.OBJ.

??

[Pylz]

C'est sûrement une question bête mais tu as inclu le fichier .lib dans ton projet ? Je demande ça avant de chercher plus loin...


Autre vérification d'usage...

Code :

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

1
2
3
4
5
__declspec(dllexport)  void WINAPI conv (struct MessIn *, struct MessOut *,
                    int   (*)(void),                    /* GetSecurity() */
                    int   (*)(void),                    /* GetKey       */
                    int   (*)(char *, int, char *),     /* GetStringFromKeyboard */
                    void  (*)(char *, int, short));     /* pos_display() */

A+

[Fbartolo]

C'est sûrement une question bête mais tu as inclu le fichier .lib dans ton projet ? Je demande ça avant de chercher plus loin...

Bah ça m'est pas venu tout de suite , mais le résultat est le même:

[LieurErreur] Unresolved external 'conv()' referenced from F:\C3KIT\DLL\TEST.OBJ.

ou alors

quote][LieurErreur] Unresolved external '_conv' referenced from F:\C3KIT\DLL\TEST.OBJ.

si je déclare la fonction par:

Code :

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

extern "C" ....

je suis décontenancé.... je vais faire un tour dans les tuto .LIB car je ne comprends plus rien c'est pourtant simple de lier un bibliothèque statique...

[Pylz]

Résumons:

1°) inclure MaDll.lib dans le projet
2°) dans MaDll.h, declarer la fonction à exporter :

Code :

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

extern "C" __declspec(dllexport) int WINAPI FonctionDll(...);

3°) Dans le module d'utilisation de la dll :

Code :

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

1
2
3
4
5
6
#include "MaDll.h"
 
void UneFonction(...)
{
     FonctionDll(...);
}

Si ça marche pas comme ça, le problème vient d'ailleurs...

Bon courage

[Fbartolo]

Alors là BRAVO ce la donne ça:

Code :

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

1
2
3
4
5
6
 
extern  "C" __declspec(dllexport) void WINAPI conv (struct tpvMessIn *, struct tpvMessOut *,
                   int   (*)(void),                    /* GetSecurity() */
                   int   (*)(void),                    /* GetKey       */
                   int   (*)(char *, int, char *),     /* GetStringFromKeyboard */
                   void  (*)(char *, int, short));     /* pos_display() */

dans le module livré il y avait aussi une LIB qui me générait ça:

[LieurErreur] 'F:\C3KIT\DLL\CONV.LIB' contains invalid OMF record, type 0x21.

le Lib je l'ai généré depuis la DLL avec IMPLIB.EXE...

autre précision:
que l'on renseigne le fichier map avec

ALLLIB = $(LIBFILES) import32.lib cw32mt.lib CONV.LIB

ou que l'on rajoute CONV.LIB au projet c'est pareil....

ça compile bien, ça link ya pu qu'à faire marcher..

MerciMerci

sinon pourquoi

WINAPI

???

[Trap D]

Ta Dll a été écrite avec Visual C ?

[Pylz]

WINAPI est un #define de Borland qui remplace la convention d'appel de fonction __cdecl ou __stdcall (selon l'environnement...).

les conventions d'appel dispo sont __cdecl, __stdcall, __fastcall, __pascal...

Consulte l'aide de Borland à ce sujet, c'est assez bien expliqué.

Bon courage pour la suite..

[Pylz]

Et oublie pas de cliquer sur 'Resolu'...si ton problème est résolu

A+

[Trap D]

Sinon, moi j'ai l'habitude de faire un LoadLibrary suivi d'un GetProcAdress toi tu le fais en faisant (char *)1 et ça fonctionne très bien entre Borland et Visual C.
Perso j'avais toujours pensé que c'était l'intérêt des Dll, on les charge en dynamique comme ça si elles sont défectueuses, il n'y a qu'elle à changer 8)

[Pylz]

Bonjour,

Ce n'est pas parcequ'on utilise le .lib que la Dll est compilé avec le prog. Le fichier lib ne sert que d'interface au moment de la conception mais la dll est toujours appelée au moment de l'execution, ce qui permet effectivement d'en changer sans avoir à recompiler... du moment que les protos des fonctions exportees sont les mêmes.

Je vois au moins trois moyens principaux de charger un Dll :

Le chargement 'normal', la dll est chargée en mémoire au lancement de l'appli, ses fonctions sont exportées à ce moment là.

Le chargement retardé, la dll n'est chargée en mémoire qu'au moment de sa premiere utilisation, ce qui permet d'éviter les plantages si un dll est absente ou corompue mais qu'elle ne sert pas forcément.

Le mappage (comme tu fais avec LoadLibrary et GetProcAddress), ca ressemble au chargement retardé mais là on maitrise mieux le processus...

Dans tous les cas, la dll etv ses fonctions ne sont pas compilés avec le prog. Par contre si quelqu'un connait un moyen de faire ça, ça ça m'interesse...

A+

[Trap D]

Ben tu vois, j'aurais au moins appris ça aujourd'hui !