C'est juste pour dire que 'extern "C" _declspec(dllexport)'
ca marche tres bien.
Merci, ca va grandement me faciliter les choses.
A +
BENB
silmalik a écrit a écrit :
Je n'y comprend trop rien, mais comme je supprime ces infos dans la DLL compilée et que ca marche , il semble bien
que ces infos ne soient pas necessaires.
Pour les paramètres de compilation ...bah y'en a trop!
C'est dingue ce truc, j'ai essayé sur d'autres PC et c'est la
même chose, ca existe les service-packs pour Visual Studio ?
Merci pour votre attention.
En fait ces decorations servent a differencier les surcharges de fonctions, donc s'il y a surcharge il faut des decorations, sinon ce n'est pas indispensable...
poue "enveler" les decorations le plus simple est d'utiliser le extern "C"...
haahhahahaha
j'ai pas tout lu donc je sais pas si sa a été déja dit mais utiliser extern "c"
Amadeus
Mais bon tu peux tjs utiliser les def comme les autres ont explique.
[edit]--Message édité par Amadeus--[/edit]
Amadeus
Comme dit + haut le pb vient du fait que le nom de tes fonctions exportees est decore. Pour eviter que le c++ ne le fait une decl et une def de type :
extern "C" _declspec(dllexport) int MaFonction();
gilou
Justement, si tu veux pas y acceder par ordinal, tu emploies la syntaxe nom_exporte = nom_decore
c'est ce que je precisais dans mon dernier post.
A+,
youdontcare
gilou a écrit a écrit :
>("??4CEsDLL@@QAEAAV0@ABV0@@Z" à la place de "EsDLL" )
donc dans ta ligne tu met:
EsDLL=??4CEsDLL@@QAEAAV0@ABV0@@Z a priori (pas sur pour les 2 ?? du debut)
A+,
pas besoin de spécifier le nom décoré de la fonction.
la seule fois ou j'ai testé les .defs, je n'ai réussi à exporter que par ordinal, comme dans l'exemple ci-dessus. à noter que le nom du .def doit être le même que celui du projet (.dsw)
gilou
>("??4CEsDLL@@QAEAAV0@ABV0@@Z" à la place de "EsDLL" )
donc dans ta ligne tu met:
EsDLL=??4CEsDLL@@QAEAAV0@ABV0@@Z a priori (pas sur pour les 2 ?? du debut)
A+,
gilou
Voici ce que dit la doc MS:
EXPORTS
Syntax
EXPORTS definitions
This statement makes one or more definitions available as exports to other programs.
EXPORTS marks the beginning of a list of export definitions. Each definition must be on a separate line. The EXPORTS keyword can be on the same line as the first definition or on a preceding line. The .DEF file can contain one or more EXPORTS statements.
The optional keyword PRIVATE prevents entryname from being placed in the import library generated by LINK. It has no effect on the export in the image also generated by LINK.
There are three methods for exporting a definition, listed in recommended order of use:
The __declspec(dllexport) keyword in the source code
An EXPORTS statement in a .DEF file
An /EXPORT specification in a LINK command All three methods can be used in the same program. When LINK builds a program that contains exports, it also creates an import library, unless an .EXP file is used in the build.
A+,
gilou
C'est un fichier externe ou tu files toutes les infos relatives a ta DLL: fctions exportees, tiens voici un exemple (modifie) tout bete:
En gros, ca marche comment les .DEF ?
(Ca avait plutot l'air simple avec dllexport)
silmalik
En gros, ca marche comment les .DEF ?
(Ca avait plutot l'air simple avec dllexport)
silmalik
Je n'y comprend trop rien, mais comme je supprime ces infos dans la DLL compilée et que ca marche , il semble bien
que ces infos ne soient pas necessaires.
Pour les paramètres de compilation ...bah y'en a trop!
C'est dingue ce truc, j'ai essayé sur d'autres PC et c'est la
même chose, ca existe les service-packs pour Visual Studio ?
Merci pour votre attention.
gilou
a la limite, utilises un fichier .def avec une section EXPORTS pout ta dll, ca reglera les chose.
A+,
youdontcare
silmalik a écrit a écrit :
Pour l'importation j'ai repris la syntaxe d'un exemple donné
dans MSDN et ca marche bien.
Lorsque je regarde d'autres DLL, les noms des modules exportés
apparaissent correctement.
Pis les DLL que j'ai modifiées sont fonctionnelles, le
'decorating' ne doit pas être essentiel, on pourrait pas le zapper ?
comme dit plus haut, ça sert au linker à connaître les types utilisés par la fonction. donc c'est absolument nécessaire :D par contre l'info doit pouvoir être exportée autrement, tu devrais chercher dans les paramètres de compilation.
silmalik
Gilou -> Tout a fait, pour être exact:
__declspec(dllexport) ...declaration de fonction
silmalik
Pour l'importation j'ai repris la syntaxe d'un exemple donné
dans MSDN et ca marche bien.
Lorsque je regarde d'autres DLL, les noms des modules exportés
apparaissent correctement.
Pis les DLL que j'ai modifiées sont fonctionnelles, le
'decorating' ne doit pas être essentiel, on pourrait pas le zapper ?
gilou
t'as utilise la feature dllexport dans ton code c++?
A+,
youdontcare
les noms des fonctions sont tout à faits normaux, ça s'appelle le 'name decorating' et ça sert à encoder le type de la variable de retour ainsi que les types des paramètres (@u= unsigned int par ex).
j'ai jamais fait de vb, mais le problème doit venir de la façon dont tu importes la dll.
silmalik
Ah, au fait, j'utilise Visual Studio 6
Sous win2k ou 95 c'est la même chose.
silmalik
Bon,
j'essaie de faire un programme interfacé en VB qui utilise
des fonctions d'une DLL que je crée en C++,
Je déclare mes fonctions exportées mais impossible
de les utilisées en VB (entry point not found).
J'ai regardé avec un désassembleur la DLL, et il s'avert que les noms des fonctions crées sont n'importe quoi !!!
("??4CEsDLL@@QAEAAV0@ABV0@@Z" à la place de "EsDLL" )
Avec un éditeur hexa je rattrape le coup, mais c'est LOURD !
