Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Environnement Microsoft LoadLibrary et GetProcAddress

LoadLibrary et GetProcAddress

40 réponses
Avatar
PurL
Bonjour,

Comment, dans un programme, peut-on utiliser les fonctions LoadLibrary et
GetProcAddress (faisant parties de l'API windows), sans inclure le .h
correspondant ?

PurL
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2 3 4
Avatar
Vincent Burel
"PurL" wrote in message
news:bmh2ek$g4j$
Fabien SK wrote:
> Fabien SK wrote:
>
>> Essaye ça:
>>
>> __declspec(dllimport) FARPROC __stdcall GetProcAddress(HMODULE
>> hModule, LPCSTR lpProcName );
>>
>
> J'oubliais: marche avec VC6...

FARPROC, HMODULE et LPCSTR sont des .h

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é :(



suffit de remplacer les types par qqc d'équivalent...

__declspec(dllimport) void * __stdcall GetProcAddress(unsigned long
hModule, char * lpProcName );

Je ne comprend pas bien votre but.
Vincent Burel
Avatar
PurL
> suffit de remplacer les types par qqc d'équivalent...

__declspec(dllimport) void * __stdcall GetProcAddress(unsigned long
hModule, char * lpProcName );



c'est exactement ce que j'ai dit :) :

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.





et j'obtiens toujours la meme erreur :(


Je ne comprend pas bien votre but.



C'est une application qui sera distribuée avec le compilateur CPP de Borland
car elle sera capable de créér des dll puis de les utilisées juste après
(une sorte de plug'in) les fonctions disponibles dans ces dll seront
appelées par le couple LoadLibrary/GetProcAddress indirectement par le
programme puisqu'il ne peut connaitre avant le nom des dll et des fonctions
de ce fait je créée un DLL charnière "sur mesure" appelant les dll deja
existantes puis executant les nouvelles fonctions de l'utilisateurs.

C'est pas évident à expliquer mais pour résumer, je ne veux pas avoir à
distribuer tout le compilateur si je n'utilise que
LoadLibrary/GetProcAddress en API !

Vincent Burel



PurL
Avatar
Cyrille \cns\ Szymanski
>> Je ne comprend pas bien votre but.



C'est une application qui sera distribuée avec le compilateur CPP de
Borland car elle sera capable de créér des dll puis de les utilisées
juste après (une sorte de plug'in) les fonctions disponibles dans ces
dll seront appelées par le couple LoadLibrary/GetProcAddress
indirectement par le programme puisqu'il ne peut connaitre avant le
nom des dll et des fonctions de ce fait je créée un DLL charnière "sur
mesure" appelant les dll deja existantes puis executant les nouvelles
fonctions de l'utilisateurs.

C'est pas évident à expliquer mais pour résumer, je ne veux pas avoir
à distribuer tout le compilateur si je n'utilise que
LoadLibrary/GetProcAddress en API !



En faisant un tri grossier des headers a mon avis tu peux réduire le
dossier de 38 Mo à 5 ou 6 Mo et garder tout plein de prototypes et types
windows.

--
_|_|_| CnS
_|_| for(n=0;b;n++)
_| b&=b-1; /*pp.47 K&R*/
Avatar
Vincent Burel
"PurL" wrote in message
news:bmh4u9$rc5$
> suffit de remplacer les types par qqc d'équivalent...
>
> __declspec(dllimport) void * __stdcall GetProcAddress(unsigned long
> hModule, char * lpProcName );

c'est exactement ce que j'ai dit :) :

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

et j'obtiens toujours la meme erreur :(



ha, ok , vous ne comprenez pas les erreur de votre linker :-)

Error: Unresolved external 'GetProcAddress(unsigned int, const char *)'
referenced from C:MADLL.OBJ

Alors ca, veut dire que votre code compilé MADLL.OBJ (donc la compilation
s'est bien passé) appelle une fonction que le linker ne connais pas .
Autrement dit une fonction que le Linker ne peut lister nulpart dans la
liste de LIB qu'il a en magazin. C'est donc que vous avez oubliez de de
stipuler le Kernel32.lib au Linker, dans la liste des lib à linker...

> Je ne comprend pas bien votre but.

C'est une application qui sera distribuée avec le compilateur CPP de


Borland
car elle sera capable de créér des dll puis de les utilisées juste après
(une sorte de plug'in) les fonctions disponibles dans ces dll seront
appelées par le couple LoadLibrary/GetProcAddress indirectement par le
programme puisqu'il ne peut connaitre avant le nom des dll et des


fonctions
de ce fait je créée un DLL charnière "sur mesure" appelant les dll deja
existantes puis executant les nouvelles fonctions de l'utilisateurs.

C'est pas évident à expliquer mais pour résumer, je ne veux pas avoir à
distribuer tout le compilateur si je n'utilise que
LoadLibrary/GetProcAddress en API !



comprend toujours pas, Borland distribue bien une windows.h et un
kernel32.lib.
Je fais du plug-in et du hosting depuis des lustre, j'ai jamais vu un
intérêt à me passer des header de la WIN32 API

a+
Vincent Burel
Avatar
Fabien SK
On Tue, 14 Oct 2003 17:02:57 +0200, Vincent Burel wrote:

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



Arggggg ! Quand je dis "statiquement", c'est que ton module a besoin de
XXX.dll pour se charger. Quand tu fais un "Dependancy Walker"
(http://www.dependencywalker.com/), tu vois bien que ton programme a
besoin de telle ou telle DLL pour être chargé par le système. Bien
sûr, on n'inclut pas le code des DLLs tierces dans son programme (sinon
çà ne s'appellerait pas des DLLs).
Avatar
Fabien SK
> ha, ok , vous ne comprenez pas les erreur de votre linker :-)

Error: Unresolved external 'GetProcAddress(unsigned int, const char *)'
referenced from C:MADLL.OBJ

Alors ca, veut dire que votre code compilé MADLL.OBJ (donc la compilation
s'est bien passé) appelle une fonction que le linker ne connais pas .
Autrement dit une fonction que le Linker ne peut lister nulpart dans la
liste de LIB qu'il a en magazin. C'est donc que vous avez oubliez de de
stipuler le Kernel32.lib au Linker, dans la liste des lib à linker...



Ce n'est pas exactement ça. La fonction "GetProcAddress" existe bien pour
le linker à mon avis, mais il ne déclare pas le bon prototype. Pour avoir
le bon prototype (plus exactement la convention d'appel: comment les
paramètres sont passés par la pile).
Avatar
Fabien SK
On Tue, 14 Oct 2003 17:34:08 +0200, PurL wrote:

C'est une application qui sera distribuée avec le compilateur CPP de Borland
car elle sera capable de créér des dll puis de les utilisées juste après
(une sorte de plug'in) les fonctions disponibles dans ces dll seront
appelées par le couple LoadLibrary/GetProcAddress indirectement par le
programme puisqu'il ne peut connaitre avant le nom des dll et des fonctions
de ce fait je créée un DLL charnière "sur mesure" appelant les dll deja
existantes puis executant les nouvelles fonctions de l'utilisateurs.

C'est pas évident à expliquer mais pour résumer, je ne veux pas avoir à
distribuer tout le compilateur si je n'utilise que
LoadLibrary/GetProcAddress en API !



Au pire, ton programme ayant les fonctions "LoadLibrary" et
"GetProcAddress", il peut les filer à ta "DLL charnière". Sauf qu'il te
faut le bon prototype, sinon les paramètres seront mal passés à ces
fonctions (=> boom).

Au fait, si tu fais ça en C, ça résoudra peut-être une partie du problème (pas de
décoration des noms en C)

Je ne peux pas trop t'aider, j'ai Visual C++ au boulot (et g++ chez moi)...
Avatar
Vincent Burel
"Fabien SK" <fabsk+ wrote in message
news:
On Tue, 14 Oct 2003 17:02:57 +0200, Vincent Burel wrote:

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

Arggggg ! Quand je dis "statiquement", c'est que ton module a besoin de
XXX.dll pour se charger. Quand tu fais un "Dependancy Walker"
(http://www.dependencywalker.com/), tu vois bien que ton programme a
besoin de telle ou telle DLL pour être chargé par le système. Bien
sûr, on n'inclut pas le code des DLLs tierces dans son programme (sinon
çà ne s'appellerait pas des DLLs).



Ha bon, si vous le voyait comme ca... si vous voulez, m'enfin usuellement un
Link static c'est quand le linker inclut le code dans votre programme ,
c'est ce qu'il fait avec les OBJ (les version compilé de vos .C) et c'est ce
qu'il fait avec vos éventuelle LIB propriétaires...

ceci explique peut-être pourquoi j'ai eu du mal à vous suivre.

Vincent Burel
Avatar
Vincent Burel
"Fabien SK" <fabsk+ wrote in message
news:
> ha, ok , vous ne comprenez pas les erreur de votre linker :-)
>
> Error: Unresolved external 'GetProcAddress(unsigned int, const char *)'
> referenced from C:MADLL.OBJ
>
> Alors ca, veut dire que votre code compilé MADLL.OBJ (donc la


compilation
> s'est bien passé) appelle une fonction que le linker ne connais pas .
> Autrement dit une fonction que le Linker ne peut lister nulpart dans la
> liste de LIB qu'il a en magazin. C'est donc que vous avez oubliez de de
> stipuler le Kernel32.lib au Linker, dans la liste des lib à linker...

Ce n'est pas exactement ça. La fonction "GetProcAddress" existe bien pour
le linker à mon avis, mais il ne déclare pas le bon prototype. Pour avoir
le bon prototype (plus exactement la convention d'appel: comment les
paramètres sont passés par la pile).



C'est vous qui l'avez donné le prototype ! et je ne vois pas en quoi il
n'est pas conforme.
la convention d'appel c'est réglé, c'est du "stdcall" et y'a pas
d'inderterminé la dessus.

Vincent Burel
Avatar
AMcD
Fabien SK wrote:

Arggggg ! Quand je dis "statiquement", c'est que ton module a besoin
de XXX.dll pour se charger. Quand tu fais un "Dependancy Walker"
(http://www.dependencywalker.com/), tu vois bien que ton programme a
besoin de telle ou telle DLL pour être chargé par le système. Bien
sûr, on n'inclut pas le code des DLLs tierces dans son programme
(sinon çà ne s'appellerait pas des DLLs).



Hem, t'es sûr là ? Statique c'est l'inverse de ce que tu dis. Toi, ce que tu
nous décrit c'est du dynamique...

--
AMcD

http://arnold.mcdonald.free.fr/
1 2 3 4