Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary et
GetProcAddress (faisant parties de l'API windows), sans inclure le .h
correspondant ?
Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary et GetProcAddress (faisant parties de l'API windows), sans inclure le .h correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll va dépendre statiquement de kernel32.dll
PurL wrote:
Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary et
GetProcAddress (faisant parties de l'API windows), sans inclure le .h
correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code.
C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll
va dépendre statiquement de kernel32.dll
Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary et GetProcAddress (faisant parties de l'API windows), sans inclure le .h correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll va dépendre statiquement de kernel32.dll
PurL
Re,
Après quelque recherche, il faut linker avec kernel32.lib. Mais je veux me passer de windows.h
Or je n'arrive pas à traduire exactement la déclaration...
WINBASEAPI FARPROC WINAPI GetProcAddress( IN HMODULE hModule, IN LPCSTR lpProcName );
Ce sont pleins de types qui s'enchiainent et qui dépendent d'autres types et de #define !! Il n'y a pas de déclarations plus simple ? j'avais penser à : extern void *GetProcAddress(unsigned int hlib, const char *fct);
mais le linker me donne : Error: Unresolved external 'GetProcAddress(unsigned int, const char *)' referenced from C:MADLL.OBJ
comment dire au linker d'aller chercher la fonction dans kernel32.lib et non dans mon obj ?
Merci pour votre aide,
PurL
Re,
Après quelque recherche, il faut linker avec kernel32.lib.
Mais je veux me passer de windows.h
Or je n'arrive pas à traduire exactement la déclaration...
WINBASEAPI
FARPROC
WINAPI
GetProcAddress(
IN HMODULE hModule,
IN LPCSTR lpProcName
);
Ce sont pleins de types qui s'enchiainent et qui dépendent d'autres types et
de #define !!
Il n'y a pas de déclarations plus simple ?
j'avais penser à :
extern void *GetProcAddress(unsigned int hlib, const char *fct);
mais le linker me donne :
Error: Unresolved external 'GetProcAddress(unsigned int, const char *)'
referenced from C:MADLL.OBJ
comment dire au linker d'aller chercher la fonction dans kernel32.lib et non
dans mon obj ?
Après quelque recherche, il faut linker avec kernel32.lib. Mais je veux me passer de windows.h
Or je n'arrive pas à traduire exactement la déclaration...
WINBASEAPI FARPROC WINAPI GetProcAddress( IN HMODULE hModule, IN LPCSTR lpProcName );
Ce sont pleins de types qui s'enchiainent et qui dépendent d'autres types et de #define !! Il n'y a pas de déclarations plus simple ? j'avais penser à : extern void *GetProcAddress(unsigned int hlib, const char *fct);
mais le linker me donne : Error: Unresolved external 'GetProcAddress(unsigned int, const char *)' referenced from C:MADLL.OBJ
comment dire au linker d'aller chercher la fonction dans kernel32.lib et non dans mon obj ?
Merci pour votre aide,
PurL
Vincent Burel
"Fabien SK" <fabsk+ wrote in message news:3f8bffcd$0$13285$
PurL wrote:
> Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary
et
> GetProcAddress (faisant parties de l'API windows), sans inclure le .h > correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll va dépendre statiquement de kernel32.dll
s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
Rappel : le header .H sert au compilateur pour connaitre le prototype des fonctions de la DLL que l'on va utiliser. Le .LIB sert au linker pour explicitement mettre dans l'exécutable les références à la DLL en question et les fonctions utilisée (le système fera le reste quand le programme sera lancé). notons que dans ce cas, le .LIB ne contient pas de code mais une liste de référence à une ou plusieurs DLL , compatible et compréhensible par le Linker de votre compilateur. C'est d'ailleurs pour cela que les environnement de développement fournissent un petit utilitaire de fabrication de .LIB à partir d'une DLL.
Bref, dans le cas où l'on fait un loadLibrary, le Linker ne rentre plus en jeu. C'est votre programme qui fait le travail. Il charge lui-même la DLL en mémoire et obtient ensuite les pointeurs sur les fonctions désirés à l'aide de GetProcAddress. Il suffit alors de mettre cette adresse dans un pointeur typé sur le prototype de fonction ad hoc, et le tour est joué...
A+ Vincent Burel
"Fabien SK" <fabsk+news@free.fr> wrote in message
news:3f8bffcd$0$13285$626a54ce@news.free.fr...
PurL wrote:
> Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary
et
> GetProcAddress (faisant parties de l'API windows), sans inclure le .h
> correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code.
C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll
va dépendre statiquement de kernel32.dll
s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB
Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre
statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
Rappel :
le header .H sert au compilateur pour connaitre le prototype des fonctions
de la DLL que l'on va utiliser.
Le .LIB sert au linker pour explicitement mettre dans l'exécutable les
références à la DLL en question et les fonctions utilisée (le système fera
le reste quand le programme sera lancé).
notons que dans ce cas, le .LIB ne contient pas de code mais une liste de
référence à une ou plusieurs DLL , compatible et compréhensible par le
Linker de votre compilateur. C'est d'ailleurs pour cela que les
environnement de développement fournissent un petit utilitaire de
fabrication de .LIB à partir d'une DLL.
Bref, dans le cas où l'on fait un loadLibrary, le Linker ne rentre plus en
jeu. C'est votre programme qui fait le travail. Il charge lui-même la DLL en
mémoire et obtient ensuite les pointeurs sur les fonctions désirés à l'aide
de GetProcAddress. Il suffit alors de mettre cette adresse dans un pointeur
typé sur le prototype de fonction ad hoc, et le tour est joué...
"Fabien SK" <fabsk+ wrote in message news:3f8bffcd$0$13285$
PurL wrote:
> Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary
et
> GetProcAddress (faisant parties de l'API windows), sans inclure le .h > correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll va dépendre statiquement de kernel32.dll
s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
Rappel : le header .H sert au compilateur pour connaitre le prototype des fonctions de la DLL que l'on va utiliser. Le .LIB sert au linker pour explicitement mettre dans l'exécutable les références à la DLL en question et les fonctions utilisée (le système fera le reste quand le programme sera lancé). notons que dans ce cas, le .LIB ne contient pas de code mais une liste de référence à une ou plusieurs DLL , compatible et compréhensible par le Linker de votre compilateur. C'est d'ailleurs pour cela que les environnement de développement fournissent un petit utilitaire de fabrication de .LIB à partir d'une DLL.
Bref, dans le cas où l'on fait un loadLibrary, le Linker ne rentre plus en jeu. C'est votre programme qui fait le travail. Il charge lui-même la DLL en mémoire et obtient ensuite les pointeurs sur les fonctions désirés à l'aide de GetProcAddress. Il suffit alors de mettre cette adresse dans un pointeur typé sur le prototype de fonction ad hoc, et le tour est joué...
A+ Vincent Burel
Fabien SK
Vincent Burel wrote:
"Fabien SK" <fabsk+ wrote in message news:3f8bffcd$0$13285$
PurL wrote:
Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary
et
GetProcAddress (faisant parties de l'API windows), sans inclure le .h correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll va dépendre statiquement de kernel32.dll
s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
"kernel32.lib" _fait_ que le programme va dépendre statiquement de "kernel32.dll". Je ne connais pas d'autre moyen d'utiliser "LoadLibrary" que de linker statiquement avec "kernel32.dll".
Vincent Burel wrote:
"Fabien SK" <fabsk+news@free.fr> wrote in message
news:3f8bffcd$0$13285$626a54ce@news.free.fr...
PurL wrote:
Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary
et
GetProcAddress (faisant parties de l'API windows), sans inclure le .h
correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code.
C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll
va dépendre statiquement de kernel32.dll
s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB
Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre
statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
"kernel32.lib" _fait_ que le programme va dépendre statiquement de
"kernel32.dll".
Je ne connais pas d'autre moyen d'utiliser "LoadLibrary" que de linker
statiquement avec "kernel32.dll".
"Fabien SK" <fabsk+ wrote in message news:3f8bffcd$0$13285$
PurL wrote:
Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary
et
GetProcAddress (faisant parties de l'API windows), sans inclure le .h correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll va dépendre statiquement de kernel32.dll
s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
"kernel32.lib" _fait_ que le programme va dépendre statiquement de "kernel32.dll". Je ne connais pas d'autre moyen d'utiliser "LoadLibrary" que de linker statiquement avec "kernel32.dll".
Fabien SK
PurL wrote:
Après quelque recherche, il faut linker avec kernel32.lib. Mais je veux me passer de windows.h
Or je n'arrive pas à traduire exactement la déclaration...
WINBASEAPI FARPROC WINAPI GetProcAddress( IN HMODULE hModule, IN LPCSTR lpProcName );
Ce sont pleins de types qui s'enchiainent et qui dépendent d'autres types et de #define !!
Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary et GetProcAddress (faisant parties de l'API windows), sans inclure le .h correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll va dépendre statiquement de kernel32.dll
Merci de ta réponse, voir message plus bas
PurL
Fabien SK wrote:
PurL wrote:
Comment, dans un programme, peut-on utiliser les fonctions
LoadLibrary et GetProcAddress (faisant parties de l'API windows),
sans inclure le .h correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton
code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou
ta .dll va dépendre statiquement de kernel32.dll
Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary et GetProcAddress (faisant parties de l'API windows), sans inclure le .h correspondant ?
Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll va dépendre statiquement de kernel32.dll
Merci de ta réponse, voir message plus bas
PurL
PurL
> Bref, dans le cas où l'on fait un loadLibrary, le Linker ne rentre plus en jeu. C'est votre programme qui fait le travail. Il charge lui-même la DLL en mémoire et obtient ensuite les pointeurs sur les fonctions désirés à l'aide de GetProcAddress.
Je suis d'accord sur le role de LoadLibray/GetProcAddress pour linker des DLL dynamiquement mais il faut au moins que le programme est connaissance de ces 2 fonctions.
Voir message plus bas,
PurL
> Bref, dans le cas où l'on fait un loadLibrary, le Linker ne rentre
plus en jeu. C'est votre programme qui fait le travail. Il charge
lui-même la DLL en mémoire et obtient ensuite les pointeurs sur les
fonctions désirés à l'aide de GetProcAddress.
Je suis d'accord sur le role de LoadLibray/GetProcAddress pour linker des
DLL dynamiquement mais il faut au moins que le programme est connaissance de
ces 2 fonctions.
> Bref, dans le cas où l'on fait un loadLibrary, le Linker ne rentre plus en jeu. C'est votre programme qui fait le travail. Il charge lui-même la DLL en mémoire et obtient ensuite les pointeurs sur les fonctions désirés à l'aide de GetProcAddress.
Je suis d'accord sur le role de LoadLibray/GetProcAddress pour linker des DLL dynamiquement mais il faut au moins que le programme est connaissance de ces 2 fonctions.
Je ne peux inclure aucun .h ou alors un .h tout simple mais dans ce cas autant mettre les typedef dans le cpp. J'en ai profité pour les remplacé par des types connus tels que "const char *" pour LPCSTR mais le linker me met toujours la meme erreur.
Je ne peux inclure aucun .h ou alors un .h tout simple mais dans ce cas
autant mettre les typedef dans le cpp.
J'en ai profité pour les remplacé par des types connus tels que "const char
*" pour LPCSTR mais le linker me met toujours la meme erreur.
Je ne peux inclure aucun .h ou alors un .h tout simple mais dans ce cas autant mettre les typedef dans le cpp. J'en ai profité pour les remplacé par des types connus tels que "const char *" pour LPCSTR mais le linker me met toujours la meme erreur.
Merci de ton aide,
je suis bloqué :(
PurL
Vincent Burel
"Fabien SK" <fabsk+ wrote in message news:3f8c06e0$0$13282$
Vincent Burel wrote:
> "Fabien SK" <fabsk+ wrote in message > news:3f8bffcd$0$13285$ > >>PurL wrote: >> >> >>>Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary > > et > >>>GetProcAddress (faisant parties de l'API windows), sans inclure le .h >>>correspondant ? >> >>Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. >>C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll >>va dépendre statiquement de kernel32.dll > > s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB > Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre > statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
"kernel32.lib" _fait_ que le programme va dépendre statiquement de "kernel32.dll". Je ne connais pas d'autre moyen d'utiliser "LoadLibrary" que de linker statiquement avec "kernel32.dll".
Kernel32 n'est jamais linké statiquement, dans le sens ou le code de Kernel32 n'est j'amais inclu dans votre logiciel à vous...
Pour le reste j'ai manifestement pas bien compris la question originale :-)
A+ Vincent Burel
"Fabien SK" <fabsk+news@free.fr> wrote in message
news:3f8c06e0$0$13282$626a54ce@news.free.fr...
Vincent Burel wrote:
> "Fabien SK" <fabsk+news@free.fr> wrote in message
> news:3f8bffcd$0$13285$626a54ce@news.free.fr...
>
>>PurL wrote:
>>
>>
>>>Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary
>
> et
>
>>>GetProcAddress (faisant parties de l'API windows), sans inclure le .h
>>>correspondant ?
>>
>>Le .h n'est pas important. Tu peux réécrire le prototype dans ton code.
>>C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll
>>va dépendre statiquement de kernel32.dll
>
> s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB
> Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre
> statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
"kernel32.lib" _fait_ que le programme va dépendre statiquement de
"kernel32.dll".
Je ne connais pas d'autre moyen d'utiliser "LoadLibrary" que de linker
statiquement avec "kernel32.dll".
Kernel32 n'est jamais linké statiquement, dans le sens ou le code de
Kernel32 n'est j'amais inclu dans votre logiciel à vous...
Pour le reste j'ai manifestement pas bien compris la question originale :-)
"Fabien SK" <fabsk+ wrote in message news:3f8c06e0$0$13282$
Vincent Burel wrote:
> "Fabien SK" <fabsk+ wrote in message > news:3f8bffcd$0$13285$ > >>PurL wrote: >> >> >>>Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary > > et > >>>GetProcAddress (faisant parties de l'API windows), sans inclure le .h >>>correspondant ? >> >>Le .h n'est pas important. Tu peux réécrire le prototype dans ton code. >>C'est le .lib qu'il te faut, ce qu'il va faire que ton .exe ou ta .dll >>va dépendre statiquement de kernel32.dll > > s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du .LIB > Ensuite le .LIB ne fait pas du tout que l'EXE ou la DLL va dépendre > statiquement de kernel32.dll (ce qui n'a d'ailleurs pas guère de sens).
"kernel32.lib" _fait_ que le programme va dépendre statiquement de "kernel32.dll". Je ne connais pas d'autre moyen d'utiliser "LoadLibrary" que de linker statiquement avec "kernel32.dll".
Kernel32 n'est jamais linké statiquement, dans le sens ou le code de Kernel32 n'est j'amais inclu dans votre logiciel à vous...
Pour le reste j'ai manifestement pas bien compris la question originale :-)
