Erreur de compilation en C pour DLL utilisable dans Windows...
8 réponses
Raymond H.
>> Voici les seules lignes que j'ai dans 'fichier.c':
>> -----------------------
>> int Addition(int Val1,int Val2)
>> {
>> return((int)(Val1 + Val2));
>> }
>> ------------------------
> Si Addition() est une fonction exportée par la DLL, elle doit s'écrire :
> -----------------------
> DLLIMPORT int Addition(int Val1,int Val2)
> {
> return(Val1 + Val2);
> }
> ------------------------
La DLL serait utilisée par un projet VB. Un projet VB enverrai une text
à la DLL, qui elle, le transforme puis le renvoie au projet VB pour que ce
projet VB continue son traitement. J'ai ajouté DLLIMPORT int...
comme vous l'avez écrit et l'erreur suivante est listée:
18 C:\RH\Codes\Codes Visual Basic\Projet vb RH\AllCrypter\En francais\Extra
AllCrypter\Clef modifiée\DLL\AllCrypter.c syntax error before "int"
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Burel
"Raymond H." wrote in message news:XnrRd.30356$
>> Voici les seules lignes que j'ai dans 'fichier.c': >> ----------------------- >> int Addition(int Val1,int Val2) >> { >> return((int)(Val1 + Val2)); >> } >> ------------------------ > Si Addition() est une fonction exportée par la DLL, elle doit s'écrire : > ----------------------- > DLLIMPORT int Addition(int Val1,int Val2) > { > return(Val1 + Val2); > } > ------------------------
La DLL serait utilisée par un projet VB. Un projet VB enverrai une
text
à la DLL, qui elle, le transforme puis le renvoie au projet VB pour que ce projet VB continue son traitement. J'ai ajouté DLLIMPORT int... comme vous l'avez écrit et l'erreur suivante est listée: 18 C:RHCodesCodes Visual BasicProjet vb RHAllCrypterEn
francaisExtra
AllCrypterClef modifiéeDLLAllCrypter.c syntax error before "int"
oui les spécificités de la fonction se placent entre le type retrourné et le nom de la fonction. il faut écrire donc :
int DLLIMPORT Addition(int Val1,int Val2)
remarquez que DLLIMPORT veut dire que vous importez cette fonction, qu'elle se trouve dans une autre lib, je suppose que vous voulez exporter cette fonction auquel cas vous devriez écrire un truc du genre :
int DLLEXPORT Addition(int Val1,int Val2)
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier .DEF qui liste les fonctions à exporter. de plus si vous voulez utilisez vos fonction en Visual Basic, il faudra les déclarer en __stdcall (type standart de protocole d'appel).
donc vous définissez votre fonction comme int __stdcall Addition(int Val1,int Val2) { return(Val1 + Val2); }
et vous faite un fichier DEF comme suit : LIBRARY DESCRIPTION 'calcul' EXPORTS Addition
Si vous voulez exporter une autre fonction vous rajoutez : EXPORTS Addition Soustraction Division etc...
Ca garantie en plus que le nom de fonction sera exporté exactement sous cette forme (pas de mangling)
A+ VB
"Raymond H." <divers_rh@hotmail.com> wrote in message
news:XnrRd.30356$4I5.1291644@news20.bellglobal.com...
>> Voici les seules lignes que j'ai dans 'fichier.c':
>> -----------------------
>> int Addition(int Val1,int Val2)
>> {
>> return((int)(Val1 + Val2));
>> }
>> ------------------------
> Si Addition() est une fonction exportée par la DLL, elle doit s'écrire :
> -----------------------
> DLLIMPORT int Addition(int Val1,int Val2)
> {
> return(Val1 + Val2);
> }
> ------------------------
La DLL serait utilisée par un projet VB. Un projet VB enverrai une
text
à la DLL, qui elle, le transforme puis le renvoie au projet VB pour que ce
projet VB continue son traitement. J'ai ajouté DLLIMPORT int...
comme vous l'avez écrit et l'erreur suivante est listée:
18 C:RHCodesCodes Visual BasicProjet vb RHAllCrypterEn
francaisExtra
AllCrypterClef modifiéeDLLAllCrypter.c syntax error before "int"
oui les spécificités de la fonction se placent entre le type retrourné et le
nom de la fonction. il faut écrire donc :
int DLLIMPORT Addition(int Val1,int Val2)
remarquez que DLLIMPORT veut dire que vous importez cette fonction, qu'elle
se trouve dans une autre lib, je suppose que vous voulez exporter cette
fonction auquel cas vous devriez écrire un truc du genre :
int DLLEXPORT Addition(int Val1,int Val2)
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier
.DEF qui liste les fonctions à exporter.
de plus si vous voulez utilisez vos fonction en Visual Basic, il faudra les
déclarer en __stdcall (type standart de protocole d'appel).
donc vous définissez votre fonction comme
int __stdcall Addition(int Val1,int Val2)
{
return(Val1 + Val2);
}
et vous faite un fichier DEF comme suit :
LIBRARY
DESCRIPTION 'calcul'
EXPORTS Addition
Si vous voulez exporter une autre fonction vous rajoutez :
EXPORTS Addition
Soustraction
Division
etc...
Ca garantie en plus que le nom de fonction sera exporté exactement sous
cette forme (pas de mangling)
>> Voici les seules lignes que j'ai dans 'fichier.c': >> ----------------------- >> int Addition(int Val1,int Val2) >> { >> return((int)(Val1 + Val2)); >> } >> ------------------------ > Si Addition() est une fonction exportée par la DLL, elle doit s'écrire : > ----------------------- > DLLIMPORT int Addition(int Val1,int Val2) > { > return(Val1 + Val2); > } > ------------------------
La DLL serait utilisée par un projet VB. Un projet VB enverrai une
text
à la DLL, qui elle, le transforme puis le renvoie au projet VB pour que ce projet VB continue son traitement. J'ai ajouté DLLIMPORT int... comme vous l'avez écrit et l'erreur suivante est listée: 18 C:RHCodesCodes Visual BasicProjet vb RHAllCrypterEn
francaisExtra
AllCrypterClef modifiéeDLLAllCrypter.c syntax error before "int"
oui les spécificités de la fonction se placent entre le type retrourné et le nom de la fonction. il faut écrire donc :
int DLLIMPORT Addition(int Val1,int Val2)
remarquez que DLLIMPORT veut dire que vous importez cette fonction, qu'elle se trouve dans une autre lib, je suppose que vous voulez exporter cette fonction auquel cas vous devriez écrire un truc du genre :
int DLLEXPORT Addition(int Val1,int Val2)
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier .DEF qui liste les fonctions à exporter. de plus si vous voulez utilisez vos fonction en Visual Basic, il faudra les déclarer en __stdcall (type standart de protocole d'appel).
donc vous définissez votre fonction comme int __stdcall Addition(int Val1,int Val2) { return(Val1 + Val2); }
et vous faite un fichier DEF comme suit : LIBRARY DESCRIPTION 'calcul' EXPORTS Addition
Si vous voulez exporter une autre fonction vous rajoutez : EXPORTS Addition Soustraction Division etc...
Ca garantie en plus que le nom de fonction sera exporté exactement sous cette forme (pas de mangling)
A+ VB
Pierre Maurette
Vincent Burel a écrit : [...]
oui les spécificités de la fonction se placent entre le type retrourné et le nom de la fonction. il faut écrire donc :
int DLLIMPORT Addition(int Val1,int Val2)
remarquez que DLLIMPORT veut dire que vous importez cette fonction, qu'elle se trouve dans une autre lib, je suppose que vous voulez exporter cette fonction auquel cas vous devriez écrire un truc du genre :
int DLLEXPORT Addition(int Val1,int Val2)
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier .DEF qui liste les fonctions à exporter. de plus si vous voulez utilisez vos fonction en Visual Basic, il faudra les déclarer en __stdcall (type standart de protocole d'appel).
donc vous définissez votre fonction comme int __stdcall Addition(int Val1,int Val2) { return(Val1 + Val2); }
et vous faite un fichier DEF comme suit : LIBRARY DESCRIPTION 'calcul' EXPORTS Addition
Si vous voulez exporter une autre fonction vous rajoutez : EXPORTS Addition Soustraction Division etc...
Ca garantie en plus que le nom de fonction sera exporté exactement sous cette forme (pas de mangling)
Le problème de Raymond est un peu particulier. Il utilise VB et ne maîtrise pas encore parfaitement le C. Il a donc choisi DevC++ pour écrire des DLL sans trop de prendre la tête. La fonction Addition() vient d'un squelette de projet qui compilait et s'exécutait parfaitement. Même chez Raymond, il me semble.
Le Wizard de DevC++ crée un xxxdll.h qui contient:
DLLIMPORT void HelloWorld () { MessageBox (0, "Hello World from DLL!n", "Hi", MB_ICONINFORMATION); }
Bien entendu, il ne fait pas tout bricoler à la main, enlever des #include, renommer des fichiers. Sinon, ça ne sert à rien d'utiliser un IDE.
-- Pierre
Vincent Burel a écrit :
[...]
oui les spécificités de la fonction se placent entre le type retrourné et le
nom de la fonction. il faut écrire donc :
int DLLIMPORT Addition(int Val1,int Val2)
remarquez que DLLIMPORT veut dire que vous importez cette fonction, qu'elle
se trouve dans une autre lib, je suppose que vous voulez exporter cette
fonction auquel cas vous devriez écrire un truc du genre :
int DLLEXPORT Addition(int Val1,int Val2)
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier
.DEF qui liste les fonctions à exporter.
de plus si vous voulez utilisez vos fonction en Visual Basic, il faudra les
déclarer en __stdcall (type standart de protocole d'appel).
donc vous définissez votre fonction comme
int __stdcall Addition(int Val1,int Val2)
{
return(Val1 + Val2);
}
et vous faite un fichier DEF comme suit :
LIBRARY
DESCRIPTION 'calcul'
EXPORTS Addition
Si vous voulez exporter une autre fonction vous rajoutez :
EXPORTS Addition
Soustraction
Division
etc...
Ca garantie en plus que le nom de fonction sera exporté exactement sous
cette forme (pas de mangling)
Le problème de Raymond est un peu particulier. Il utilise VB et ne
maîtrise pas encore parfaitement le C. Il a donc choisi DevC++ pour
écrire des DLL sans trop de prendre la tête. La fonction Addition()
vient d'un squelette de projet qui compilait et s'exécutait
parfaitement. Même chez Raymond, il me semble.
Le Wizard de DevC++ crée un xxxdll.h qui contient:
oui les spécificités de la fonction se placent entre le type retrourné et le nom de la fonction. il faut écrire donc :
int DLLIMPORT Addition(int Val1,int Val2)
remarquez que DLLIMPORT veut dire que vous importez cette fonction, qu'elle se trouve dans une autre lib, je suppose que vous voulez exporter cette fonction auquel cas vous devriez écrire un truc du genre :
int DLLEXPORT Addition(int Val1,int Val2)
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier .DEF qui liste les fonctions à exporter. de plus si vous voulez utilisez vos fonction en Visual Basic, il faudra les déclarer en __stdcall (type standart de protocole d'appel).
donc vous définissez votre fonction comme int __stdcall Addition(int Val1,int Val2) { return(Val1 + Val2); }
et vous faite un fichier DEF comme suit : LIBRARY DESCRIPTION 'calcul' EXPORTS Addition
Si vous voulez exporter une autre fonction vous rajoutez : EXPORTS Addition Soustraction Division etc...
Ca garantie en plus que le nom de fonction sera exporté exactement sous cette forme (pas de mangling)
Le problème de Raymond est un peu particulier. Il utilise VB et ne maîtrise pas encore parfaitement le C. Il a donc choisi DevC++ pour écrire des DLL sans trop de prendre la tête. La fonction Addition() vient d'un squelette de projet qui compilait et s'exécutait parfaitement. Même chez Raymond, il me semble.
Le Wizard de DevC++ crée un xxxdll.h qui contient:
DLLIMPORT void HelloWorld () { MessageBox (0, "Hello World from DLL!n", "Hi", MB_ICONINFORMATION); }
Bien entendu, il ne fait pas tout bricoler à la main, enlever des #include, renommer des fichiers. Sinon, ça ne sert à rien d'utiliser un IDE.
-- Pierre
Vincent Burel
"Pierre Maurette" wrote in message news:
Vincent Burel a écrit : [...]
Le problème de Raymond est un peu particulier. Il utilise VB et ne maîtrise pas encore parfaitement le C. Il a donc choisi DevC++ pour écrire des DLL sans trop de prendre la tête.
Bien entendu, il ne fait pas tout bricoler à la main, enlever des #include, renommer des fichiers. Sinon, ça ne sert à rien d'utiliser un
IDE.
Mouai, un IDE ca ne sert pas à programmer à la place du programmeur non plus. enfin bon...
VB
"Pierre Maurette" <maurettepierre@wanadoo.fr> wrote in message
news:37od8sF5gcki8U1@individual.net...
Vincent Burel a écrit :
[...]
Le problème de Raymond est un peu particulier. Il utilise VB et ne
maîtrise pas encore parfaitement le C. Il a donc choisi DevC++ pour
écrire des DLL sans trop de prendre la tête.
Le problème de Raymond est un peu particulier. Il utilise VB et ne maîtrise pas encore parfaitement le C. Il a donc choisi DevC++ pour écrire des DLL sans trop de prendre la tête.
Bien entendu, il ne fait pas tout bricoler à la main, enlever des #include, renommer des fichiers. Sinon, ça ne sert à rien d'utiliser un
IDE.
Mouai, un IDE ca ne sert pas à programmer à la place du programmeur non plus. enfin bon...
VB
Arnaud Debaene
Vincent Burel wrote:
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier .DEF qui liste les fonctions à exporter.
Historiquement, __declspec(dllexport) est apparu des années après les fichiers .DEF, pour répondre au porblème de l'exportation des classes C++ où on a *besoin* que les symboles exportés soient manglés.
Arnaud
Vincent Burel wrote:
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un
fichier .DEF qui liste les fonctions à exporter.
Historiquement, __declspec(dllexport) est apparu des années après les
fichiers .DEF, pour répondre au porblème de l'exportation des classes C++ où
on a *besoin* que les symboles exportés soient manglés.
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier .DEF qui liste les fonctions à exporter.
Historiquement, __declspec(dllexport) est apparu des années après les fichiers .DEF, pour répondre au porblème de l'exportation des classes C++ où on a *besoin* que les symboles exportés soient manglés.
Arnaud
Vincent Burel
"Arnaud Debaene" wrote in message news:42172371$0$15589$
Vincent Burel wrote: > Cependant l'usage n'est plus d'utiliser ces macro, on utilise un > fichier .DEF qui liste les fonctions à exporter. Historiquement, __declspec(dllexport) est apparu des années après les fichiers .DEF, pour répondre au porblème de l'exportation des classes C++
où
on a *besoin* que les symboles exportés soient manglés.
possible, cependant __declspec(dllexport) est définit comme obsolete dans les doc Microsoft il me semble...
En outre, je parlais de la fabrication d'une DLL en "C" , et dans ce cas, on veut généralement éviter d'avoir du mangling, justement pour être compatible avec tout language.
VB
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:42172371$0$15589$626a14ce@news.free.fr...
Vincent Burel wrote:
> Cependant l'usage n'est plus d'utiliser ces macro, on utilise un
> fichier .DEF qui liste les fonctions à exporter.
Historiquement, __declspec(dllexport) est apparu des années après les
fichiers .DEF, pour répondre au porblème de l'exportation des classes C++
où
on a *besoin* que les symboles exportés soient manglés.
possible, cependant __declspec(dllexport) est définit comme obsolete dans
les doc Microsoft il me semble...
En outre, je parlais de la fabrication d'une DLL en "C" , et dans ce cas, on
veut généralement éviter d'avoir du mangling, justement pour être compatible
avec tout language.
"Arnaud Debaene" wrote in message news:42172371$0$15589$
Vincent Burel wrote: > Cependant l'usage n'est plus d'utiliser ces macro, on utilise un > fichier .DEF qui liste les fonctions à exporter. Historiquement, __declspec(dllexport) est apparu des années après les fichiers .DEF, pour répondre au porblème de l'exportation des classes C++
où
on a *besoin* que les symboles exportés soient manglés.
possible, cependant __declspec(dllexport) est définit comme obsolete dans les doc Microsoft il me semble...
En outre, je parlais de la fabrication d'une DLL en "C" , et dans ce cas, on veut généralement éviter d'avoir du mangling, justement pour être compatible avec tout language.
VB
AMcD®
Arnaud Debaene wrote:
Historiquement, __declspec(dllexport) est apparu des années après les fichiers .DEF, pour répondre au porblème de l'exportation des classes C++ où on a *besoin* que les symboles exportés soient manglés.
C'est surtout apparu pour se passer des .DEF :-).
-- AMcD®
http://arnold.mcdonald.free.fr/
Arnaud Debaene wrote:
Historiquement, __declspec(dllexport) est apparu des années après les
fichiers .DEF, pour répondre au porblème de l'exportation des classes
C++ où on a *besoin* que les symboles exportés soient manglés.
Historiquement, __declspec(dllexport) est apparu des années après les fichiers .DEF, pour répondre au porblème de l'exportation des classes C++ où on a *besoin* que les symboles exportés soient manglés.
C'est surtout apparu pour se passer des .DEF :-).
-- AMcD®
http://arnold.mcdonald.free.fr/
Arnaud Debaene
Vincent Burel wrote:
"Arnaud Debaene" wrote in message news:42172371$0$15589$
Vincent Burel wrote:
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier .DEF qui liste les fonctions à exporter.
Historiquement, __declspec(dllexport) est apparu des années après les fichiers .DEF, pour répondre au porblème de l'exportation des classes C++ où on a *besoin* que les symboles exportés soient manglés.
possible, cependant __declspec(dllexport) est définit comme obsolete dans les doc Microsoft il me semble...
Ah. Où çà? Ils proposent quoi à la place? Certainement pas les .def!
Arnaud
Vincent Burel wrote:
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:42172371$0$15589$626a14ce@news.free.fr...
Vincent Burel wrote:
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un
fichier .DEF qui liste les fonctions à exporter.
Historiquement, __declspec(dllexport) est apparu des années après les
fichiers .DEF, pour répondre au porblème de l'exportation des
classes C++ où on a *besoin* que les symboles exportés soient
manglés.
possible, cependant __declspec(dllexport) est définit comme obsolete
dans les doc Microsoft il me semble...
Ah. Où çà? Ils proposent quoi à la place? Certainement pas les .def!
"Arnaud Debaene" wrote in message news:42172371$0$15589$
Vincent Burel wrote:
Cependant l'usage n'est plus d'utiliser ces macro, on utilise un fichier .DEF qui liste les fonctions à exporter.
Historiquement, __declspec(dllexport) est apparu des années après les fichiers .DEF, pour répondre au porblème de l'exportation des classes C++ où on a *besoin* que les symboles exportés soient manglés.
possible, cependant __declspec(dllexport) est définit comme obsolete dans les doc Microsoft il me semble...
Ah. Où çà? Ils proposent quoi à la place? Certainement pas les .def!
Arnaud
Vincent Burel
"Arnaud Debaene" wrote in message news:4218aaf5$0$29191$
Vincent Burel wrote: > "Arnaud Debaene" wrote in message > news:42172371$0$15589$ >> Vincent Burel wrote: > possible, cependant __declspec(dllexport) est définit comme obsolete > dans les doc Microsoft il me semble...
Ah. Où çà? Ils proposent quoi à la place? Certainement pas les .def!
nulpart, j'ai du confondre avec le __export keyword.
VB
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:4218aaf5$0$29191$636a15ce@news.free.fr...
Vincent Burel wrote:
> "Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
> news:42172371$0$15589$626a14ce@news.free.fr...
>> Vincent Burel wrote:
> possible, cependant __declspec(dllexport) est définit comme obsolete
> dans les doc Microsoft il me semble...
Ah. Où çà? Ils proposent quoi à la place? Certainement pas les .def!
nulpart, j'ai du confondre avec le __export keyword.
"Arnaud Debaene" wrote in message news:4218aaf5$0$29191$
Vincent Burel wrote: > "Arnaud Debaene" wrote in message > news:42172371$0$15589$ >> Vincent Burel wrote: > possible, cependant __declspec(dllexport) est définit comme obsolete > dans les doc Microsoft il me semble...
Ah. Où çà? Ils proposent quoi à la place? Certainement pas les .def!
nulpart, j'ai du confondre avec le __export keyword.
