Discussion :

[castorcharly]

Bonjour,
J'ai les sources en C d'une application qui utilise des .LIB. Je dispose de ces .LIB ainsi que des .DLL du même nom.
Je cherche à rééecrire ce programme sous Delphi 2006, mais je n'arrive pas à utiliser ces .LIB.

D'autre part je tente de trouver les functions exportées dans les .DLL, mais je n'arrive pas à les retrouver. J'utilise dependency walker pour trouver les functions exportées.
Dans les .LIB en C je vois bien les appels aux functions, mais quand je regarde dans les .DLL les exports, si je trouve des functions correspondantes, elles commencent par un point d'interrogation et je ne peux les charger avec getProcAdress.

J'ai parcouru tous les exports et pas moyen de trouver un export qui correspond aux functions dont j'ai besoin.
Par exemple:
Dans le code C que j'ai, il y a un appel du type :
Eobj.Reco(&Z1,256,crClasse,cBuffer);

Je cherche donc Reco comme function exportée dans le jeu de DLL et je trouve ?Reco.
Si j'arrive bien à charger la DLL concernée, la function Reco ou ?Reco me renvoie Nil sur le GetProcAdress.

Par contre si je prends une autre DLL de ce jeu, dont les exports sont bien nommés, comme dans mes propres DLL, le GetProcAdress est cohérent.

Il me reste une autre solution, c'est de tenter d'utiliser les .LIB directement dans mon code Delphi, mais je ne sais comment faire. Je pense à un include ou autre pour inclure ces .LIB à mon projet, mais je ne sais comment faire.

Avez-vous déjà utilisé des .LIB pour le C dans un projet Delphi et si oui comment avez-vous fait vos déclarations ?


Merci pour votre aide...

[Paul TOTH]

en C il est possible de "mangler" les fonctions, elles ont alors une codification qui permet de connaître le nombre et le type des paramètres, c'est peut-être le cas de ces DLL.

ceci dit le getProcAddress fonctionne malgré tout.

maintenant si ce sont des objets C++ c'est très compliqué à utiliser dans Delphi - j'ai exploré ça à l'époque de Kylix pour faire du QT sans le wrapper Borland - la solution est d'ailleurs généralement d'utiliser un wrapper C qui remet à plat les fonctions.

[castorcharly]

en C il est possible de "mangler" les fonctions, elles ont alors une codification qui permet de connaître le nombre et le type des paramètres, c'est peut-être le cas de ces DLL.

ceci dit le getProcAddress fonctionne malgré tout.

maintenant si ce sont des objets C++ c'est très compliqué à utiliser dans Delphi - j'ai exploré ça à l'époque de Kylix pour faire du QT sans le wrapper Borland - la solution est d'ailleurs généralement d'utiliser un wrapper C qui remet à plat les fonctions.

Bonjour,

Si je comprends bien, il n'y a pas de différence (d'un point de vue des fonctionnalités) entre utiliser un .LIB et utiliser le .DLL.


Les fonctions accessibles sont les mêmes et puisque j'arrive à charger puis utiliser des fonctions exportées sur certaine de ces DLL, je dois pouvoir utiliser celles que je vois dans le code C quand il utilise les .LIB ?

Donc c'est simplement que je suis un manche en C

[Paul TOTH]

Bonjour,

Si je comprends bien, il n'y a pas de différence (d'un point de vue des fonctionnalités) entre utiliser un .LIB et utiliser le .DLL.


Les fonctions accessibles sont les mêmes et puisque j'arrive à charger puis utiliser des fonctions exportées sur certaine de ces DLL, je dois pouvoir utiliser celles que je vois dans le code C quand il utilise les .LIB ?

Donc c'est simplement que je suis un manche en C

un .LIB peut contenir tout et n'importe quoi...mais c'est inexploitable dans Delphi

le problème que j'avais avec QT par exemple, c'est que les DLL exposent des objets, que les .h permettent d'utiliser...mais les .h contenaient également du code C qu'il fallait donc reproduire dans Delphi pour pouvoir utiliser la DLL (le .so dans le cas de Kylix sous Linux).

le .LIB c'est du code précompilé, ça peut être simplement ce qu'il faut pour charger la DLL, mais ça peut très bien contenir du code spécifique qu'il faut recréer dans Delphi...sans les sources c'est difficile à savoir.

[castorcharly]

un .LIB peut contenir tout et n'importe quoi...mais c'est inexploitable dans Delphi

le problème que j'avais avec QT par exemple, c'est que les DLL exposent des objets, que les .h permettent d'utiliser...mais les .h contenaient également du code C qu'il fallait donc reproduire dans Delphi pour pouvoir utiliser la DLL (le .so dans le cas de Kylix sous Linux).

le .LIB c'est du code précompilé, ça peut être simplement ce qu'il faut pour charger la DLL, mais ça peut très bien contenir du code spécifique qu'il faut recréer dans Delphi...sans les sources c'est difficile à savoir.

Merci pour ces précisions,
je sais dans qu'elle direction chercher maintenant.
je clos le sujet