Je voudrais, depuis mon programme principal, lancer une fonction qui se
trouve dans une dll en lui passant un paramètre (lpbuffer) qui est l'adresse
d'un buffer du prog principal afin que la fonction dll puisse le lire.
Tout d'abord quand je ne passe pas de paramètre, je fais ceci et ça marche
très bien :
4.- dllEntryAdd1(); // ici ma dll chargée dans mon prog principal démarre
correctement (sans paramètre ça marche)
Lorsque je veux passer le paramètre lpbuffer j'obtiens des erreurs de compil
sur le prog ppal (donc sans rapport avec la présentation côté dll puisque je
ne vais pas jusqu'au link) !
Lorsque je modifie uniquement la ligne 4 comme ci-dessous :
et ça marche impeccable, sauf que maintenant j'ai un problème dans ma DLL,
mais peut-être allez-vous me dire que c'est normal :
Dans mon point d'entrée ci-dessus (dllEntryAdd1) de ma dll, je me contente de récupérer l'adresse lpcheminlog qui est l'adresse dans mon programme principal du chemin d'un fichier dans lequel ma dll écrira un peu plus tard et je fais passer cette adresse en variable globale de ma dll (Nomfichier = lpcheminlog) (Nomfichier est une variable globale). Je me contente ensuite toujours dans le même point d'entrée de ma dll de lancer un hook pour récupérer les touches du clavier et je reviens immédiatement dans mon programme principal qui lui contient la boucle Getmessage.
Il faut préciser que la callback de traitement des touches se trouve dans ma dll et c'est elle qui ira écrire dans le fichier dont le chemin est dans le programme principal et l'adresse de ce chemin en variable globale de ma dll.
Je tape une ou deux touches tout se passe bien, puis tout à coup la variable globale de ma dll (Nomfichier) perd l'adresse du buffer du programme principal qui contient le nom du fichier. Est-ce normal ? J'ai essayé de mettre Nomfichier en variable static mais ça ne change rien !
Faut-il que je recopie le chemin du fichier (et pas seulement son adresse) dans une variable globale de ma dll ?
Merci
Bon finalement pour lancer l'exécution de ma dll en lui passant l'adresse
d'un buffer en paramètre, j'ai trouvé ça:
et ça marche impeccable, sauf que maintenant j'ai un problème dans ma DLL,
mais peut-être allez-vous me dire que c'est normal :
Dans mon point d'entrée ci-dessus (dllEntryAdd1) de ma dll, je me contente
de récupérer l'adresse lpcheminlog qui est l'adresse dans mon programme
principal du chemin d'un fichier dans lequel ma dll écrira un peu plus tard
et je fais passer cette adresse en variable globale de ma dll (Nomfichier =
lpcheminlog) (Nomfichier est une variable globale). Je me contente ensuite
toujours dans le même point d'entrée de ma dll de lancer un hook pour
récupérer les touches du clavier et je reviens immédiatement dans mon
programme principal qui lui contient la boucle Getmessage.
Il faut préciser que la callback de traitement des touches se trouve dans ma
dll et c'est elle qui ira écrire dans le fichier dont le chemin est dans le
programme principal et l'adresse de ce chemin en variable globale de ma dll.
Je tape une ou deux touches tout se passe bien, puis tout à coup la variable
globale de ma dll (Nomfichier) perd l'adresse du buffer du programme
principal qui contient le nom du fichier. Est-ce normal ? J'ai essayé de
mettre Nomfichier en variable static mais ça ne change rien !
Faut-il que je recopie le chemin du fichier (et pas seulement son adresse)
dans une variable globale de ma dll ?
et ça marche impeccable, sauf que maintenant j'ai un problème dans ma DLL,
mais peut-être allez-vous me dire que c'est normal :
Dans mon point d'entrée ci-dessus (dllEntryAdd1) de ma dll, je me contente de récupérer l'adresse lpcheminlog qui est l'adresse dans mon programme principal du chemin d'un fichier dans lequel ma dll écrira un peu plus tard et je fais passer cette adresse en variable globale de ma dll (Nomfichier = lpcheminlog) (Nomfichier est une variable globale). Je me contente ensuite toujours dans le même point d'entrée de ma dll de lancer un hook pour récupérer les touches du clavier et je reviens immédiatement dans mon programme principal qui lui contient la boucle Getmessage.
Il faut préciser que la callback de traitement des touches se trouve dans ma dll et c'est elle qui ira écrire dans le fichier dont le chemin est dans le programme principal et l'adresse de ce chemin en variable globale de ma dll.
Je tape une ou deux touches tout se passe bien, puis tout à coup la variable globale de ma dll (Nomfichier) perd l'adresse du buffer du programme principal qui contient le nom du fichier. Est-ce normal ? J'ai essayé de mettre Nomfichier en variable static mais ça ne change rien !
Faut-il que je recopie le chemin du fichier (et pas seulement son adresse) dans une variable globale de ma dll ?
Merci
Christian ASTOR
Roger a écrit :
Je tape une ou deux touches tout se passe bien, puis tout à coup la variable globale de ma dll (Nomfichier) perd l'adresse du buffer du programme principal qui contient le nom du fichier. Est-ce normal ? J'ai essayé de mettre Nomfichier en variable static mais ça ne change rien !
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un "shared data segment" pour les variables globales (#pragma data_seg)
Roger a écrit :
Je tape une ou deux touches tout se passe bien, puis tout à coup la variable
globale de ma dll (Nomfichier) perd l'adresse du buffer du programme
principal qui contient le nom du fichier. Est-ce normal ? J'ai essayé de
mettre Nomfichier en variable static mais ça ne change rien !
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un
"shared data segment" pour les variables globales
(#pragma data_seg)
Je tape une ou deux touches tout se passe bien, puis tout à coup la variable globale de ma dll (Nomfichier) perd l'adresse du buffer du programme principal qui contient le nom du fichier. Est-ce normal ? J'ai essayé de mettre Nomfichier en variable static mais ça ne change rien !
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un "shared data segment" pour les variables globales (#pragma data_seg)
Roger
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un "shared data segment" pour les variables globales (#pragma data_seg)
D'après ce que je viens de voir sur Internet à propos de #pragma data_seg, j'ai compris que ceci sert à créer une section commune de communication entre deux exec. Mais il ne me semble pas que ce soit exactement ça mon problème. J'ai si on veut deux exec: celui de mon programme principal et celui de ma dll qui contient plusieurs fonctions. Chaque exec a ses propres variables globales indépendantes. Lorsque je charge la dll dans mon programme principal et que je lance l'exécution de la première fonction de la dll, je lui passe en paramètre l'adresse d'un buffer qui est dans mon programme principal. Côté dll je mets l'adresse de ce buffer dans une variable globale de ma dll, puis je n'y touche plus, or après quelques secondes de fonctionnement je m'aperçois que soit l'adresse de ce buffer que j'avais mise dans ma variable globale de ma dll a disparu, soit elle y est encore mais elle ne pointe plus sur le buffer initial. Pourtant la dll étant chargée lors de l'exécution dans le corps du programme principal, il n'y a pas de raison que son emplacement relatif change. Mais je peux me tromper!
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un
"shared data segment" pour les variables globales
(#pragma data_seg)
D'après ce que je viens de voir sur Internet à propos de #pragma data_seg,
j'ai compris que ceci sert à créer une section commune de communication
entre deux exec. Mais il ne me semble pas que ce soit exactement ça mon
problème. J'ai si on veut deux exec: celui de mon programme principal et
celui de ma dll qui contient plusieurs fonctions. Chaque exec a ses propres
variables globales indépendantes. Lorsque je charge la dll dans mon
programme principal et que je lance l'exécution de la première fonction de
la dll, je lui passe en paramètre l'adresse d'un buffer qui est dans mon
programme principal. Côté dll je mets l'adresse de ce buffer dans une
variable globale de ma dll, puis je n'y touche plus, or après quelques
secondes de fonctionnement je m'aperçois que soit l'adresse de ce buffer que
j'avais mise dans ma variable globale de ma dll a disparu, soit elle y est
encore mais elle ne pointe plus sur le buffer initial. Pourtant la dll étant
chargée lors de l'exécution dans le corps du programme principal, il n'y a
pas de raison que son emplacement relatif change. Mais je peux me tromper!
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un "shared data segment" pour les variables globales (#pragma data_seg)
D'après ce que je viens de voir sur Internet à propos de #pragma data_seg, j'ai compris que ceci sert à créer une section commune de communication entre deux exec. Mais il ne me semble pas que ce soit exactement ça mon problème. J'ai si on veut deux exec: celui de mon programme principal et celui de ma dll qui contient plusieurs fonctions. Chaque exec a ses propres variables globales indépendantes. Lorsque je charge la dll dans mon programme principal et que je lance l'exécution de la première fonction de la dll, je lui passe en paramètre l'adresse d'un buffer qui est dans mon programme principal. Côté dll je mets l'adresse de ce buffer dans une variable globale de ma dll, puis je n'y touche plus, or après quelques secondes de fonctionnement je m'aperçois que soit l'adresse de ce buffer que j'avais mise dans ma variable globale de ma dll a disparu, soit elle y est encore mais elle ne pointe plus sur le buffer initial. Pourtant la dll étant chargée lors de l'exécution dans le corps du programme principal, il n'y a pas de raison que son emplacement relatif change. Mais je peux me tromper!
Christian ASTOR
Roger a écrit :
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un "shared data segment" pour les variables globales (#pragma data_seg)
D'après ce que je viens de voir sur Internet à propos de #pragma data_seg, j'ai compris que ceci sert à créer une section commune de communication entre deux exec.
C'est surtout pour y mettre les variables partagées (le Hook handle en général par exemple)
Roger a écrit :
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un
"shared data segment" pour les variables globales
(#pragma data_seg)
D'après ce que je viens de voir sur Internet à propos de #pragma data_seg,
j'ai compris que ceci sert à créer une section commune de communication
entre deux exec.
C'est surtout pour y mettre les variables partagées (le Hook handle en
général par exemple)
Je n'ai pas tout suivi, mais on utilise dans les DLL de Hook un "shared data segment" pour les variables globales (#pragma data_seg)
D'après ce que je viens de voir sur Internet à propos de #pragma data_seg, j'ai compris que ceci sert à créer une section commune de communication entre deux exec.
C'est surtout pour y mettre les variables partagées (le Hook handle en général par exemple)
Roger
C'est surtout pour y mettre les variables partagées (le Hook handle en général par exemple)
Oui merci, j'ai compris entre temps que chaque fois que je tapais des caractères sur une autre fenêtre que celle de mon programme principal, c'était une autre image de ma dll qui s'exécutait. J'avais résolu provisoirement le problème en mettant les données qu'il me faut récupérer d'une exécution à l'autre dans un fichier de travail que je sauvegardais à la fin de ma callback et que je récupérais en début de callback. Ainsi tout s'est mis à fonctionner correctement. Mais depuis j'ai compris qu'il y a plus astucieux avec les segments ou les mappings.
C'est surtout pour y mettre les variables partagées (le Hook handle en
général par exemple)
Oui merci, j'ai compris entre temps que chaque fois que je tapais des
caractères sur une autre fenêtre que celle de mon programme principal,
c'était une autre image de ma dll qui s'exécutait. J'avais résolu
provisoirement le problème en mettant les données qu'il me faut récupérer
d'une exécution à l'autre dans un fichier de travail que je sauvegardais à
la fin de ma callback et que je récupérais en début de callback. Ainsi tout
s'est mis à fonctionner correctement. Mais depuis j'ai compris qu'il y a
plus astucieux avec les segments ou les mappings.
C'est surtout pour y mettre les variables partagées (le Hook handle en général par exemple)
Oui merci, j'ai compris entre temps que chaque fois que je tapais des caractères sur une autre fenêtre que celle de mon programme principal, c'était une autre image de ma dll qui s'exécutait. J'avais résolu provisoirement le problème en mettant les données qu'il me faut récupérer d'une exécution à l'autre dans un fichier de travail que je sauvegardais à la fin de ma callback et que je récupérais en début de callback. Ainsi tout s'est mis à fonctionner correctement. Mais depuis j'ai compris qu'il y a plus astucieux avec les segments ou les mappings.
