Discussion :

[Athur]

Bonjour,
Quand on fait un hook dans une DLL, il y a un petit problème à résoudre au niveau du programme principal qui lance la DLL !
En effet, la fonction DLL qui lance le HOOK revenant immédiatement dans le programme principal, il ne faut pas que le programme principal se termine, sinon la DLL se termine aussi et le HOOK est perdu !
J'ai envisagé trois solutions pour bloquer le programme principal, sur les 3, les deux premières fonctionnent très bien et je voudrais savoir, à votre avis, laquelle consomme le moins de ressources système et éventuellement si vous connaissez d'autres solutions encore plus astucieuses pour arriver au même résultat.

1ère solution qui marche: je fais une petit programme principal sans fenêtre et après l'appel de la DLL, j'utilise la fonction API32:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Sleep(INFINITE);

2ème solution qui marche: je fais un programme principal avec une fenêtre (éventuellement invisible) et après l'appel de la DLL, le programme principal reste bloqué sur sa boucle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Getmessage();

3ème solution qui ne marche pas: je fais un programme principal sans fenêtre, je m'arrange pour que l'appel de la fonction qui lance la DLL me transmette en retour le handle du HOOK, puis après le retour de la fonction DLL et toujours dans le programme principal, j'utilise la fonction API32:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WaitForSingleObjectEx(hookdll, INFINITE, false);

qui est sensée bloquer sur le non changement d'état de n'importe quel objet, mais qui visiblement ne bloque pas pour ce type d'objet.

J'ai quand même un avis sur les solutions 1 & 2, de mon point de vue, il me semble que c'est la solution 1 qui consomme le moins. A discuter donc.
Merci

[Andnotor]

Les 3 méthode sont bloquantes, donc insatisfaisantes à mon goût

La méthode 3 est la meilleure toute en y ajoutant un Time-Out pour ce ménager une porte de sortie. Maintenant que WaitForSingleObject soit sur le handle de la DLL ou un Event; A tester...

Attention tout de même à vouloir centraliser tout le code dans la DLL, ça peut très vite pénaliser le système. Si on n'a pas besoin d'interférer avec la donnée, une communication par PostMessage avec l'application principale est à mon sens bien meilleure !

[Athur]

Ok merci, je testerai le WaitForSingleObjet sur le handle de la DLL. Par contre, il me semble que le Postmessage implique de maintenir une boucle Getmessage dans le programme principal, ce qui revient à rajouter une solution 2 par dessus la solution 3 ou au minimum à la solution 2. Initialement je pensais, mais à tort semble-t-il, que la fonction Sleep ne faisait qu'armer un timer externe à l'UC, donc ne prenait pas de temps UC, sauf au départ pour armer le timer et à la fin lorsque l'interruption de déclenchement du timer arrive sur l'UC, pour traiter l'interruption et reprendre la main. Alors qu'une boucle Getmessage, me semblait-il, ne faisait que tourner dans l'UC.
A+

[Andnotor]

En fait, si tu ne mets pas de boucle pour tester au minimum un WM_CLOSE, l'application sera incapable de s'arrêter proprement et tu auras systématiquement à l'arrêt du système le message "L'application n'a pas pu se terminer..."

Il faudrait maintenant savoir ce que tu vises avec ce hook. Parce qu'à moins que tu ne l'installes que pour un Thread précis, celui-ci ne sera de toute façon jamais déchargé puisque ton application est (actuellement) bloquante.

Pour le PostMessage, ça dépend beaucoup de ce que fait ta routine. Si elle vise tous les processus, son temps de traitement, modification des données, etc.

[Athur]

Re-bonjour,
En fait mon prog ppal travaille de deux manières différentes selon qu'il est appelé manuellement par un clic sur le .exe ou selon qu'il détecte un lancement automatique au démarrage de windows.
S'il s'agit d'un appel manuel il construit une fenêtre et dans ce cas il boucle en permanence sur sa boucle Getmessage ce qui lui permet d'exécuter les différentes commandes de l'utilisateur via le menu, donc par exemple de lancer la dll du hook ou ensuite de l'arrêter.
Par contre s'il détecte un lancement auto au démarrage, il ne construit pas de fenêtre donc pas de boucle Getmessage, il se contente de lancer la dll du look et de s'endormir sur un sleep(INFINITE), car je veux effectivement que le hook soit opérationnel en permanence. A l'arrêt du système il n'y a pas de message "L'application n'a pas pu se terminer...", l'application se termine proprement, ce message n'apparaît que si le programme avait au préalable construit une fenêtre ce qui n'est pas le cas lors d'un lancement automatique au démarrage (d'aiileurs il est précisé dans la doc API32 sur la fonction Sleep qu'il faut éviter d'utiliser cette fonction avec une fenêtre).
J'ai essayé de remplacer le Sleep(INFINITE) par un WaitForSingleObject sur le handle de la dll, ça a l'air de fonctionner pareil.
J'aurais pu aussi mettre une boucle Getmessage sans fenêtre, mais je n'en vois pas l'utilité du moment que dans le cas d'un lancement auto je ne veux pas arrêter le hook de la dll jusqu'à l'arrêt du système.
En fait ma question était tout simplement d'avoir un avis sur la solution qui parmi les 3 présentées sollicitait le moins l'UC.
Merci

[Médinoc]

Franchement, je dirais construis toujours une fenêtre, mais rends-là invisible (voire message-only) en cas de lancement automatique.