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 !
 
Quelqu'un connait le problème?
 
Merci d'avance.

Ah, au fait, j'utilise Visual Studio 6
Sous win2k ou 95 c'est la même chose.

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.

t'as utilise la feature dllexport dans ton code c++?
A+,

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 -> Tout a fait, pour être exact:
 
__declspec(dllexport) ...declaration de fonction

comme dit plus haut, ça sert au linker à connaître les types utilisés par la fonction. donc c'est absolument nécessaire par contre l'info doit pouvoir être exportée autrement, tu devrais chercher dans les paramètres de compilation.

a la limite, utilises un fichier .def avec une section EXPORTS pout ta dll, ca reglera les chose.
A+,

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 gros, ca marche comment les .DEF ?
(Ca avait plutot l'air simple avec dllexport)

En gros, ca marche comment les .DEF ?
(Ca avait plutot l'air simple avec dllexport)

C'est un fichier externe ou tu files toutes les infos relatives a ta DLL: fctions exportees, tiens voici un exemple (modifie) tout bete:
 
LIBRARY         MyLibrary
EXPORTS
  VersionValidate
  Startup
  Shutdown
  Initialize
  Command
  Message
 
A+,

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 syntax for an export definition is:
 
entryname[=internalname] [@ordinal[NONAME]] [DATA] [PRIVATE]
 
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+,

>("??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.
 
à titre d'exemple, un .def d'un plugin de max :
 
LIBRARY lattice
EXPORTS
 LibDescription   @1
 LibNumberClasses  @2
 LibClassDesc   @3
 LibVersion    @4
 CanAutoDefer   @5
SECTIONS
 .data READ WRITE
 
 
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)

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+,

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();

Mais bon tu peux tjs utiliser les def comme les autres ont explique.

[edit]--Message édité par Amadeus--[/edit]

j'ai pas tout lu donc je sais pas si sa a été déja dit mais utiliser extern "c"

 
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"...

C'est juste pour dire que 'extern "C" _declspec(dllexport)'
ca marche tres bien.
 
Merci, ca va grandement me faciliter les choses.
 
A +