API32 et appel DLL

Le
Roger
Bonjour,

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 :



1.- FARPROC dllEntryAdd1;

2.- hinstdll = LoadLibrary(lpchemindll);

3.- dllEntryAdd1 = GetProcAddress(hinstdll, dllEntrySet);

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 :

1.- FARPROC dllEntryAdd1;

2.- hinstdll = LoadLibrary(lpchemindll);

3.- dllEntryAdd1 = GetProcAddress(hinstdll, dllEntrySet);

4.- dllEntryAdd1(lpbuffer);

J'obtiens l'erreur de compile suivante : « Extra parameter » sur la ligne 4



Lorsque je modifie la ligne 1 et 4 comme ci-dessous :

1.- FARPROC dllEntryAdd1(LPTSTR); //ou encore : FARPROC dllEntryAdd1(char
*p);

2.- hinstdll = LoadLibrary(lpchemindll);

3.- dllEntryAdd1 = GetProcAddress(hinstdll, dllEntrySet);

4.- dllEntryAdd1(lpbuffer);

J'obtiens l'erreur de compile suivante : « Lvalue required » sur la ligne 3



Lorsque je modifie les lignes 1, 3 et 4 comme ci-dessous :

1.- FARPROC dllEntryAdd1(LPTSTR); //ou encore : FARPROC dllEntryAdd1(char
*p);

2.- hinstdll = LoadLibrary(lpchemindll);

3.- dllEntryAdd1(lpbuffer) = GetProcAddress(hinstdll, dllEntrySet);

4.- dllEntryAdd1(lpbuffer);

J'obtiens encore l'erreur de compile suivante : « Lvalue required » sur la
ligne 3



Je sais bien que ce dernier exemple est farfelu.

Help per favor

Thanks
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Roger
Le #23200791
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:



typedef INT (WINAPI* PMAFONCTION)(char* );

PMAFONCTION dllEntryAdd1;

hinstdll = LoadLibrary(lpchemindll);

dllEntryAdd1 = (PMAFONCTION)GetProcAddress(hinstdll, dllEntrySet);

iret=dllEntryAdd1(lpcheminlog);



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
Le #23200971
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
Le #23201131
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
Le #23206741
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
Le #23214031
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.
Publicité
Poster une réponse
Anonyme