D'ailleurs (tiens, on commence à couper les cheveux en quatre), si je
dis: - "dépendance statique" et "dépendance dynamique", ça correspond
bien à
ce que je veux dire
- "link statique" et "link dynamique", c'est pas bon.
D'ailleurs (tiens, on commence à couper les cheveux en quatre), si je
dis: - "dépendance statique" et "dépendance dynamique", ça correspond
bien à
ce que je veux dire
- "link statique" et "link dynamique", c'est pas bon.
D'ailleurs (tiens, on commence à couper les cheveux en quatre), si je
dis: - "dépendance statique" et "dépendance dynamique", ça correspond
bien à
ce que je veux dire
- "link statique" et "link dynamique", c'est pas bon.
>>Comment nommes-tu le fait d'utiliser une DLL:
Préambule: son problème était d'accéder aux fonctions "LoadLibrary" et
"GetProcAddress" (ça aurait pu être "CreateWindow", le problème aurait
été le même).
Ca tombe bien, ma première réponse à PurL était:
--- citation ---
Moi: 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
---
Note que je n'ai pas écrit "linker statiquement kernel32.dll".
Ce à quoi tu me réponds:
--- citation ---
Toi: s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du
[je passe la partie où tu m'expliques ce qu'est une DLL, un .LIB et un
Vu qu'il veut accéder à la fonction "LoadLibrary", il a besoin de
kernel.lib (tu n'avais pas compris son problème). Donc j'essaye de
reexpliquer tout ça:
--- citation ---
Moi: "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".
---
OK, j'ai dit "linker statiquement". Mais tout de même, je t'ai parlé
deux fois de dépendance statique au dessus.
>>Comment nommes-tu le fait d'utiliser une DLL:
Préambule: son problème était d'accéder aux fonctions "LoadLibrary" et
"GetProcAddress" (ça aurait pu être "CreateWindow", le problème aurait
été le même).
Ca tombe bien, ma première réponse à PurL était:
--- citation ---
Moi: 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
---
Note que je n'ai pas écrit "linker statiquement kernel32.dll".
Ce à quoi tu me réponds:
--- citation ---
Toi: s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du
[je passe la partie où tu m'expliques ce qu'est une DLL, un .LIB et un
Vu qu'il veut accéder à la fonction "LoadLibrary", il a besoin de
kernel.lib (tu n'avais pas compris son problème). Donc j'essaye de
reexpliquer tout ça:
--- citation ---
Moi: "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".
---
OK, j'ai dit "linker statiquement". Mais tout de même, je t'ai parlé
deux fois de dépendance statique au dessus.
>>Comment nommes-tu le fait d'utiliser une DLL:
Préambule: son problème était d'accéder aux fonctions "LoadLibrary" et
"GetProcAddress" (ça aurait pu être "CreateWindow", le problème aurait
été le même).
Ca tombe bien, ma première réponse à PurL était:
--- citation ---
Moi: 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
---
Note que je n'ai pas écrit "linker statiquement kernel32.dll".
Ce à quoi tu me réponds:
--- citation ---
Toi: s'il utilise LoadLibrary et GetProcAddress , il n'a pas besoin du
[je passe la partie où tu m'expliques ce qu'est une DLL, un .LIB et un
Vu qu'il veut accéder à la fonction "LoadLibrary", il a besoin de
kernel.lib (tu n'avais pas compris son problème). Donc j'essaye de
reexpliquer tout ça:
--- citation ---
Moi: "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".
---
OK, j'ai dit "linker statiquement". Mais tout de même, je t'ai parlé
deux fois de dépendance statique au dessus.
> oui, on se bataille sur un problème de forme sans intérêt... Faut
dire que ce thread est plus que nébuleux... D'ailleurs maintenant je
n'y comprend plus rien :-)
> oui, on se bataille sur un problème de forme sans intérêt... Faut
dire que ce thread est plus que nébuleux... D'ailleurs maintenant je
n'y comprend plus rien :-)
> oui, on se bataille sur un problème de forme sans intérêt... Faut
dire que ce thread est plus que nébuleux... D'ailleurs maintenant je
n'y comprend plus rien :-)
> A moins que tes DLLs plugins aient besoin d'appeler LoadLibray, il n'y
> a pas de problèmes, ou alors j'ai rien comris à ce que tu veux
> faire....
>
> Arnaud
Je vais essayer de réexpliquer :
Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données (comme
les macro sous excel)
De plus, l'utilisateur peut avoir accès à des dll contenant des fonctions
(que j'appelle DLL bibliothèque) (j'en ai fait une par exemple pour les
fonctions mathèmatiques COS, SIN, ...)
Quand l'utilisateur à écrit son code, le programme compile ce code pour
créer une DLL (que j'ai appellé DLL charnière) capable d'appeler les DLL
bibliothèque (dans l'exemple celle qui contient les fonctions
mathématiques).
Donc les DLL bibliothèque sont effectivement créées sur mon poste donc là,
pas de probleme mais la DLL charniere c'est le programme principale qui la
créer sur le poste de l'utilisateur. Et cette DLL charnière à besoin de
LoadLibrary / GetProcAddress / FreeLibrary pour appeler les fonctions des
DLL bibliothèques.
> A moins que tes DLLs plugins aient besoin d'appeler LoadLibray, il n'y
> a pas de problèmes, ou alors j'ai rien comris à ce que tu veux
> faire....
>
> Arnaud
Je vais essayer de réexpliquer :
Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données (comme
les macro sous excel)
De plus, l'utilisateur peut avoir accès à des dll contenant des fonctions
(que j'appelle DLL bibliothèque) (j'en ai fait une par exemple pour les
fonctions mathèmatiques COS, SIN, ...)
Quand l'utilisateur à écrit son code, le programme compile ce code pour
créer une DLL (que j'ai appellé DLL charnière) capable d'appeler les DLL
bibliothèque (dans l'exemple celle qui contient les fonctions
mathématiques).
Donc les DLL bibliothèque sont effectivement créées sur mon poste donc là,
pas de probleme mais la DLL charniere c'est le programme principale qui la
créer sur le poste de l'utilisateur. Et cette DLL charnière à besoin de
LoadLibrary / GetProcAddress / FreeLibrary pour appeler les fonctions des
DLL bibliothèques.
> A moins que tes DLLs plugins aient besoin d'appeler LoadLibray, il n'y
> a pas de problèmes, ou alors j'ai rien comris à ce que tu veux
> faire....
>
> Arnaud
Je vais essayer de réexpliquer :
Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données (comme
les macro sous excel)
De plus, l'utilisateur peut avoir accès à des dll contenant des fonctions
(que j'appelle DLL bibliothèque) (j'en ai fait une par exemple pour les
fonctions mathèmatiques COS, SIN, ...)
Quand l'utilisateur à écrit son code, le programme compile ce code pour
créer une DLL (que j'ai appellé DLL charnière) capable d'appeler les DLL
bibliothèque (dans l'exemple celle qui contient les fonctions
mathématiques).
Donc les DLL bibliothèque sont effectivement créées sur mon poste donc là,
pas de probleme mais la DLL charniere c'est le programme principale qui la
créer sur le poste de l'utilisateur. Et cette DLL charnière à besoin de
LoadLibrary / GetProcAddress / FreeLibrary pour appeler les fonctions des
DLL bibliothèques.
> Je comprends le but que vous voulez atteindre, je ne comprends pas la
méthode. Car enfin si vous voulez fournir des fonction à votre DLL
utilisateur (le plug-in), vous pouvez tout aussi bien lui fournir à
l'initialisation, une table de vecteur (qui correspondent à des
fonctions qui se trouvent ou dans votre programme principale, ou dans
un DLL linké à votre programme principale)... Toutes les DLL d'un
Process sont dans le même espace d'adressage, un Host à le droit de
prendre un pointeur de fonction dans la DLL A pour le filer à la DLL
B.
Vincent Burel
> Je comprends le but que vous voulez atteindre, je ne comprends pas la
méthode. Car enfin si vous voulez fournir des fonction à votre DLL
utilisateur (le plug-in), vous pouvez tout aussi bien lui fournir à
l'initialisation, une table de vecteur (qui correspondent à des
fonctions qui se trouvent ou dans votre programme principale, ou dans
un DLL linké à votre programme principale)... Toutes les DLL d'un
Process sont dans le même espace d'adressage, un Host à le droit de
prendre un pointeur de fonction dans la DLL A pour le filer à la DLL
B.
Vincent Burel
> Je comprends le but que vous voulez atteindre, je ne comprends pas la
méthode. Car enfin si vous voulez fournir des fonction à votre DLL
utilisateur (le plug-in), vous pouvez tout aussi bien lui fournir à
l'initialisation, une table de vecteur (qui correspondent à des
fonctions qui se trouvent ou dans votre programme principale, ou dans
un DLL linké à votre programme principale)... Toutes les DLL d'un
Process sont dans le même espace d'adressage, un Host à le droit de
prendre un pointeur de fonction dans la DLL A pour le filer à la DLL
B.
Vincent Burel
> Je comprends le but que vous voulez atteindre, je ne comprends pas la
> méthode. Car enfin si vous voulez fournir des fonction à votre DLL
> utilisateur (le plug-in), vous pouvez tout aussi bien lui fournir à
> l'initialisation, une table de vecteur (qui correspondent à des
> fonctions qui se trouvent ou dans votre programme principale, ou dans
> un DLL linké à votre programme principale)... Toutes les DLL d'un
> Process sont dans le même espace d'adressage, un Host à le droit de
> prendre un pointeur de fonction dans la DLL A pour le filer à la DLL
> B.
Je ne suis pas expert de linkage :(
Je peux compiler qqch faisant appel à des fonctions de DLL tiers en ayant
uniquement un .h et un .dll ? comment ?
Pour info j'utilise le linker de borland : ilink32.exe
> Je comprends le but que vous voulez atteindre, je ne comprends pas la
> méthode. Car enfin si vous voulez fournir des fonction à votre DLL
> utilisateur (le plug-in), vous pouvez tout aussi bien lui fournir à
> l'initialisation, une table de vecteur (qui correspondent à des
> fonctions qui se trouvent ou dans votre programme principale, ou dans
> un DLL linké à votre programme principale)... Toutes les DLL d'un
> Process sont dans le même espace d'adressage, un Host à le droit de
> prendre un pointeur de fonction dans la DLL A pour le filer à la DLL
> B.
Je ne suis pas expert de linkage :(
Je peux compiler qqch faisant appel à des fonctions de DLL tiers en ayant
uniquement un .h et un .dll ? comment ?
Pour info j'utilise le linker de borland : ilink32.exe
> Je comprends le but que vous voulez atteindre, je ne comprends pas la
> méthode. Car enfin si vous voulez fournir des fonction à votre DLL
> utilisateur (le plug-in), vous pouvez tout aussi bien lui fournir à
> l'initialisation, une table de vecteur (qui correspondent à des
> fonctions qui se trouvent ou dans votre programme principale, ou dans
> un DLL linké à votre programme principale)... Toutes les DLL d'un
> Process sont dans le même espace d'adressage, un Host à le droit de
> prendre un pointeur de fonction dans la DLL A pour le filer à la DLL
> B.
Je ne suis pas expert de linkage :(
Je peux compiler qqch faisant appel à des fonctions de DLL tiers en ayant
uniquement un .h et un .dll ? comment ?
Pour info j'utilise le linker de borland : ilink32.exe
> A moins que tes DLLs plugins aient besoin d'appeler LoadLibray, il n'y
> a pas de problèmes, ou alors j'ai rien comris à ce que tu veux
> faire....
>
> Arnaud
Je vais essayer de réexpliquer :
Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données (comme
les macro sous excel)
De plus, l'utilisateur peut avoir accès à des dll contenant des fonctions
(que j'appelle DLL bibliothèque) (j'en ai fait une par exemple pour les
fonctions mathèmatiques COS, SIN, ...)
Quand l'utilisateur à écrit son code, le programme compile ce code pour
créer une DLL (que j'ai appellé DLL charnière) capable d'appeler les DLL
bibliothèque (dans l'exemple celle qui contient les fonctions
mathématiques).
Donc les DLL bibliothèque sont effectivement créées sur mon poste donc là,
pas de probleme mais la DLL charniere c'est le programme principale qui la
créer sur le poste de l'utilisateur. Et cette DLL charnière à besoin de
LoadLibrary / GetProcAddress / FreeLibrary pour appeler les fonctions des
DLL bibliothèques.
> A moins que tes DLLs plugins aient besoin d'appeler LoadLibray, il n'y
> a pas de problèmes, ou alors j'ai rien comris à ce que tu veux
> faire....
>
> Arnaud
Je vais essayer de réexpliquer :
Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données (comme
les macro sous excel)
De plus, l'utilisateur peut avoir accès à des dll contenant des fonctions
(que j'appelle DLL bibliothèque) (j'en ai fait une par exemple pour les
fonctions mathèmatiques COS, SIN, ...)
Quand l'utilisateur à écrit son code, le programme compile ce code pour
créer une DLL (que j'ai appellé DLL charnière) capable d'appeler les DLL
bibliothèque (dans l'exemple celle qui contient les fonctions
mathématiques).
Donc les DLL bibliothèque sont effectivement créées sur mon poste donc là,
pas de probleme mais la DLL charniere c'est le programme principale qui la
créer sur le poste de l'utilisateur. Et cette DLL charnière à besoin de
LoadLibrary / GetProcAddress / FreeLibrary pour appeler les fonctions des
DLL bibliothèques.
> A moins que tes DLLs plugins aient besoin d'appeler LoadLibray, il n'y
> a pas de problèmes, ou alors j'ai rien comris à ce que tu veux
> faire....
>
> Arnaud
Je vais essayer de réexpliquer :
Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données (comme
les macro sous excel)
De plus, l'utilisateur peut avoir accès à des dll contenant des fonctions
(que j'appelle DLL bibliothèque) (j'en ai fait une par exemple pour les
fonctions mathèmatiques COS, SIN, ...)
Quand l'utilisateur à écrit son code, le programme compile ce code pour
créer une DLL (que j'ai appellé DLL charnière) capable d'appeler les DLL
bibliothèque (dans l'exemple celle qui contient les fonctions
mathématiques).
Donc les DLL bibliothèque sont effectivement créées sur mon poste donc là,
pas de probleme mais la DLL charniere c'est le programme principale qui la
créer sur le poste de l'utilisateur. Et cette DLL charnière à besoin de
LoadLibrary / GetProcAddress / FreeLibrary pour appeler les fonctions des
DLL bibliothèques.
> Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données
(comme les macro sous excel)
> Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données
(comme les macro sous excel)
> Mon programme manipule des données d'acquisition.
L'utilisateur peut ecrire du code CPP pour "jouer" avec ces données
(comme les macro sous excel)
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
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
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
Comment nommes-tu le fait d'utiliser une DLL:
- en spécifiant au link la liaison entre ton programme et la DLL ?
(chargement de la DLL lors de la création du process par le système)
- en chargeant la DLL avec "LoadLibrary" ? (chargement de la DLL pendant
l'exécution du programme)
Moi je n'ai pas d'autres mots pour dire ça. D'un coté la dépendance est
statique, et de l'autre non. Si tu as une autre manière de dire ça, je
suis preneur.
Comment nommes-tu le fait d'utiliser une DLL:
- en spécifiant au link la liaison entre ton programme et la DLL ?
(chargement de la DLL lors de la création du process par le système)
- en chargeant la DLL avec "LoadLibrary" ? (chargement de la DLL pendant
l'exécution du programme)
Moi je n'ai pas d'autres mots pour dire ça. D'un coté la dépendance est
statique, et de l'autre non. Si tu as une autre manière de dire ça, je
suis preneur.
Comment nommes-tu le fait d'utiliser une DLL:
- en spécifiant au link la liaison entre ton programme et la DLL ?
(chargement de la DLL lors de la création du process par le système)
- en chargeant la DLL avec "LoadLibrary" ? (chargement de la DLL pendant
l'exécution du programme)
Moi je n'ai pas d'autres mots pour dire ça. D'un coté la dépendance est
statique, et de l'autre non. Si tu as une autre manière de dire ça, je
suis preneur.