extern "C"
{
__declspec(dllexport) int _stdcall sivallertest(int i,int b)
{
return i*b;
}
}
extern int _stdcall sivallertest(int i,int b);
"
Le compilateur est censer de me générer une library avec vc++ avec la
routine "sivallertest" exporté.
Rapport :
Le compilateur m'exporte la routine "sivallertest" au nom de
"_sivallertest@8" au lieu de "sivallertest".
Conclusion sous delphi :
"program Project1;
{$APPTYPE CONSOLE}
function sivallertest(a,b : integer) : integer; stdcall external
'testdll2.dll';
begin
// Insérer le code utilisateur ici
writeln(sivallertest(5,20));
readln;
end.
"
Ne peux trouver la routine "sivallertest".
Conlusion :
On ne sait probablement pas créez des library multi-plateform (delphi,vc++).
Quelle (mot de passe) ou syntaxe apparament non documenté dans MSDN faut
t'il entrez dans "testdll.cpp" pour que le compilateur Vc++ m'exporte
la routine "sivallertest" au nom de "sivallertest" et non pas
"_sivaller@numeropoubelle" ??
extern "C" { __declspec(dllexport) int _stdcall sivallertest(int i,int b) { return i*b; } }
extern int _stdcall sivallertest(int i,int b); " Le compilateur est censer de me générer une library avec vc++ avec la routine "sivallertest" exporté. Rapport : Le compilateur m'exporte la routine "sivallertest" au nom de "" au lieu de "sivallertest".
Conclusion sous delphi : "program Project1; {$APPTYPE CONSOLE}
function sivallertest(a,b : integer) : integer; stdcall external 'testdll2.dll';
begin // Insérer le code utilisateur ici writeln(sivallertest(5,20)); readln; end. " Ne peux trouver la routine "sivallertest".
ben ouai !
Conlusion : On ne sait probablement pas créez des library multi-plateform
(delphi,vc++).
mais si, mais vous exportez votre fonction mangled name (nom déterioré), dans ce cas le linker fait comme il veut en fonction des option en cours...
si vous voulez exporter exactement le nom de la fonction, faites un fichier DEF avec la liste de vos fonctions à exporter (et arréter d'utiliser __declspec(dllexport))
VB
"Sivaller" <sivaller@lycos.fr> wrote in message
news:bnj78q$kbo$1@news-reader5.wanadoo.fr...
j'ai ça :
"
// testdll2.cpp : Defines the entry point for the DLL application.
//
extern "C"
{
__declspec(dllexport) int _stdcall sivallertest(int i,int b)
{
return i*b;
}
}
extern int _stdcall sivallertest(int i,int b);
"
Le compilateur est censer de me générer une library avec vc++ avec la
routine "sivallertest" exporté.
Rapport :
Le compilateur m'exporte la routine "sivallertest" au nom de
"_sivallertest@8" au lieu de "sivallertest".
Conclusion sous delphi :
"program Project1;
{$APPTYPE CONSOLE}
function sivallertest(a,b : integer) : integer; stdcall external
'testdll2.dll';
begin
// Insérer le code utilisateur ici
writeln(sivallertest(5,20));
readln;
end.
"
Ne peux trouver la routine "sivallertest".
ben ouai !
Conlusion :
On ne sait probablement pas créez des library multi-plateform
(delphi,vc++).
mais si, mais vous exportez votre fonction mangled name (nom déterioré),
dans ce cas le linker fait comme il veut en fonction des option en cours...
si vous voulez exporter exactement le nom de la fonction, faites un fichier
DEF avec la liste de vos fonctions à exporter (et arréter d'utiliser
__declspec(dllexport))
extern "C" { __declspec(dllexport) int _stdcall sivallertest(int i,int b) { return i*b; } }
extern int _stdcall sivallertest(int i,int b); " Le compilateur est censer de me générer une library avec vc++ avec la routine "sivallertest" exporté. Rapport : Le compilateur m'exporte la routine "sivallertest" au nom de "" au lieu de "sivallertest".
Conclusion sous delphi : "program Project1; {$APPTYPE CONSOLE}
function sivallertest(a,b : integer) : integer; stdcall external 'testdll2.dll';
begin // Insérer le code utilisateur ici writeln(sivallertest(5,20)); readln; end. " Ne peux trouver la routine "sivallertest".
ben ouai !
Conlusion : On ne sait probablement pas créez des library multi-plateform
(delphi,vc++).
mais si, mais vous exportez votre fonction mangled name (nom déterioré), dans ce cas le linker fait comme il veut en fonction des option en cours...
si vous voulez exporter exactement le nom de la fonction, faites un fichier DEF avec la liste de vos fonctions à exporter (et arréter d'utiliser __declspec(dllexport))
VB
Sivaller
Ca fonctionne , oui vous avez raison , faut éviter le _declspec(dllexport) Vincent Burel a écrit dans le message : bnj8sm$qh4$
"Sivaller" wrote in message news:bnj78q$kbo$ > j'ai ça : > " > // testdll2.cpp : Defines the entry point for the DLL application. > // > > #include "stdafx.h" > > BOOL APIENTRY DllMain( HANDLE hModule, > DWORD ul_reason_for_call, > LPVOID lpReserved > ) > { > return TRUE; > } > > > extern "C" > { > __declspec(dllexport) int _stdcall sivallertest(int i,int b) > { > return i*b; > } > } > > extern int _stdcall sivallertest(int i,int b); > " > Le compilateur est censer de me générer une library avec vc++ avec la > routine "sivallertest" exporté. > Rapport : > Le compilateur m'exporte la routine "sivallertest" au nom de > "" au lieu de "sivallertest". > > Conclusion sous delphi : > "program Project1; > {$APPTYPE CONSOLE} > > function sivallertest(a,b : integer) : integer; stdcall external > 'testdll2.dll'; > > begin > // Insérer le code utilisateur ici > writeln(sivallertest(5,20)); > readln; > end. > " > Ne peux trouver la routine "sivallertest".
ben ouai !
> Conlusion : > On ne sait probablement pas créez des library multi-plateform (delphi,vc++).
mais si, mais vous exportez votre fonction mangled name (nom déterioré), dans ce cas le linker fait comme il veut en fonction des option en
cours...
si vous voulez exporter exactement le nom de la fonction, faites un
fichier
DEF avec la liste de vos fonctions à exporter (et arréter d'utiliser __declspec(dllexport))
VB
Ca fonctionne , oui vous avez raison , faut éviter le _declspec(dllexport)
Vincent Burel <vincent.burel@wanadoo.fr> a écrit dans le message :
bnj8sm$qh4$1@news-reader5.wanadoo.fr...
"Sivaller" <sivaller@lycos.fr> wrote in message
news:bnj78q$kbo$1@news-reader5.wanadoo.fr...
> j'ai ça :
> "
> // testdll2.cpp : Defines the entry point for the DLL application.
> //
>
> #include "stdafx.h"
>
> BOOL APIENTRY DllMain( HANDLE hModule,
> DWORD ul_reason_for_call,
> LPVOID lpReserved
> )
> {
> return TRUE;
> }
>
>
> extern "C"
> {
> __declspec(dllexport) int _stdcall sivallertest(int i,int b)
> {
> return i*b;
> }
> }
>
> extern int _stdcall sivallertest(int i,int b);
> "
> Le compilateur est censer de me générer une library avec vc++ avec la
> routine "sivallertest" exporté.
> Rapport :
> Le compilateur m'exporte la routine "sivallertest" au nom de
> "_sivallertest@8" au lieu de "sivallertest".
>
> Conclusion sous delphi :
> "program Project1;
> {$APPTYPE CONSOLE}
>
> function sivallertest(a,b : integer) : integer; stdcall external
> 'testdll2.dll';
>
> begin
> // Insérer le code utilisateur ici
> writeln(sivallertest(5,20));
> readln;
> end.
> "
> Ne peux trouver la routine "sivallertest".
ben ouai !
> Conlusion :
> On ne sait probablement pas créez des library multi-plateform
(delphi,vc++).
mais si, mais vous exportez votre fonction mangled name (nom déterioré),
dans ce cas le linker fait comme il veut en fonction des option en
cours...
si vous voulez exporter exactement le nom de la fonction, faites un
fichier
DEF avec la liste de vos fonctions à exporter (et arréter d'utiliser
__declspec(dllexport))
Ca fonctionne , oui vous avez raison , faut éviter le _declspec(dllexport) Vincent Burel a écrit dans le message : bnj8sm$qh4$
"Sivaller" wrote in message news:bnj78q$kbo$ > j'ai ça : > " > // testdll2.cpp : Defines the entry point for the DLL application. > // > > #include "stdafx.h" > > BOOL APIENTRY DllMain( HANDLE hModule, > DWORD ul_reason_for_call, > LPVOID lpReserved > ) > { > return TRUE; > } > > > extern "C" > { > __declspec(dllexport) int _stdcall sivallertest(int i,int b) > { > return i*b; > } > } > > extern int _stdcall sivallertest(int i,int b); > " > Le compilateur est censer de me générer une library avec vc++ avec la > routine "sivallertest" exporté. > Rapport : > Le compilateur m'exporte la routine "sivallertest" au nom de > "" au lieu de "sivallertest". > > Conclusion sous delphi : > "program Project1; > {$APPTYPE CONSOLE} > > function sivallertest(a,b : integer) : integer; stdcall external > 'testdll2.dll'; > > begin > // Insérer le code utilisateur ici > writeln(sivallertest(5,20)); > readln; > end. > " > Ne peux trouver la routine "sivallertest".
ben ouai !
> Conlusion : > On ne sait probablement pas créez des library multi-plateform (delphi,vc++).
mais si, mais vous exportez votre fonction mangled name (nom déterioré), dans ce cas le linker fait comme il veut en fonction des option en
cours...
si vous voulez exporter exactement le nom de la fonction, faites un
fichier
DEF avec la liste de vos fonctions à exporter (et arréter d'utiliser __declspec(dllexport))
VB
Ambassadeur Kosh
il y a longtemps, on utilisait __export et __import. Borland faisait son mangling dans son coin et MS forcement un mangling different dans le sien. puis un jour, sont apparus les declspec(import) et declspec(export). j'utilisais Borland C++ Builder, et force était de constater que les __export d'une dll ne matchaient pas avec les declspec(import) d'un exe client. et reciproquement. donc j'en avais conclu : declspec est une "normalisation" pour que n'importe quelle dll de n'importe quel outils puisse cooperer sans se casser les burnes pendant 3 plombes avec les fichiers defs ou autres m..., concepts qui cassent facilement les c... et plus encore quand on sait qu'ils apportent à peu pres autant que les makefile faits à la main.
apparement il n'en est rien.
du coup, la question : "quel interet d'avoir viré __import pour mettre declspec(import)"
voila voila...
il y a longtemps, on utilisait __export et __import. Borland faisait son
mangling dans son coin et MS forcement un mangling different dans le sien.
puis un jour, sont apparus les declspec(import) et declspec(export).
j'utilisais Borland C++ Builder, et force était de constater que les
__export d'une dll ne matchaient pas avec les declspec(import) d'un exe
client. et reciproquement. donc j'en avais conclu : declspec est une
"normalisation" pour que n'importe quelle dll de n'importe quel outils
puisse cooperer sans se casser les burnes pendant 3 plombes avec les
fichiers defs ou autres m..., concepts qui cassent facilement les c... et
plus encore quand on sait qu'ils apportent à peu pres autant que les
makefile faits à la main.
apparement il n'en est rien.
du coup, la question : "quel interet d'avoir viré __import pour mettre
declspec(import)"
il y a longtemps, on utilisait __export et __import. Borland faisait son mangling dans son coin et MS forcement un mangling different dans le sien. puis un jour, sont apparus les declspec(import) et declspec(export). j'utilisais Borland C++ Builder, et force était de constater que les __export d'une dll ne matchaient pas avec les declspec(import) d'un exe client. et reciproquement. donc j'en avais conclu : declspec est une "normalisation" pour que n'importe quelle dll de n'importe quel outils puisse cooperer sans se casser les burnes pendant 3 plombes avec les fichiers defs ou autres m..., concepts qui cassent facilement les c... et plus encore quand on sait qu'ils apportent à peu pres autant que les makefile faits à la main.
apparement il n'en est rien.
du coup, la question : "quel interet d'avoir viré __import pour mettre declspec(import)"
voila voila...
Patrick \Zener\ BRUNET
Bonjour.
"Ambassadeur Kosh" a écrit dans le message news: bnleoo$14i$
<...> du coup, la question : "quel interet d'avoir viré __import pour mettre declspec(import)"
Si je me souviens bien, __import était une macro alors que declspec(import) serait une extension au langage dûment intégrée au compilateur. De toute manière, il y a des macros genre APIENTRY par dessus pour générer ces trucs-là. Alors moi comme je ne veux pas tout réécrire si ça change encore, j'ai mes propres macros dans le genre DYNAMIC_EXPORT, qui facilitent l'exportation. D'ailleurs il est aussi possible d'écrire une petite moulinette pour rechercher cette clé dans les sources et générer automatiquement un .def, laquelle moulinette peut être intégrée en prélude au cycle de compilation...
Bref, les normes sont faites pour être changées, et il faut essayer de s'adapter.
cordialement,
Patrick BRUNET, sur le coup depuis Windows 2
Bonjour.
"Ambassadeur Kosh" <yanapa@nospamnocry.fr> a écrit dans le message news:
bnleoo$14i$1@news-reader2.wanadoo.fr...
<...>
du coup, la question : "quel interet d'avoir viré __import pour mettre
declspec(import)"
Si je me souviens bien, __import était une macro alors que declspec(import)
serait une extension au langage dûment intégrée au compilateur.
De toute manière, il y a des macros genre APIENTRY par dessus pour générer
ces trucs-là.
Alors moi comme je ne veux pas tout réécrire si ça change encore, j'ai mes
propres macros dans le genre DYNAMIC_EXPORT, qui facilitent l'exportation.
D'ailleurs il est aussi possible d'écrire une petite moulinette pour
rechercher cette clé dans les sources et générer automatiquement un .def,
laquelle moulinette peut être intégrée en prélude au cycle de compilation...
Bref, les normes sont faites pour être changées, et il faut essayer de
s'adapter.
"Ambassadeur Kosh" a écrit dans le message news: bnleoo$14i$
<...> du coup, la question : "quel interet d'avoir viré __import pour mettre declspec(import)"
Si je me souviens bien, __import était une macro alors que declspec(import) serait une extension au langage dûment intégrée au compilateur. De toute manière, il y a des macros genre APIENTRY par dessus pour générer ces trucs-là. Alors moi comme je ne veux pas tout réécrire si ça change encore, j'ai mes propres macros dans le genre DYNAMIC_EXPORT, qui facilitent l'exportation. D'ailleurs il est aussi possible d'écrire une petite moulinette pour rechercher cette clé dans les sources et générer automatiquement un .def, laquelle moulinette peut être intégrée en prélude au cycle de compilation...
Bref, les normes sont faites pour être changées, et il faut essayer de s'adapter.
