Discussion :

[monstor]

Bonjour ,

Dans mon code si certaines conditions sont réunies je dois killer l'application word.exe mais je en vois pas du tout comment faire.

Merci pour votre aide !

[Melem]

Tuer une application n'est jamais une bonne idée et ne peut se faire en C++ standard. Sous Windows cela peut se faire avec la fonction TerminateProcess et sous Linux avec la fonction kill.

[monstor]

Malheureusmeent je ne commais pas lme PID du processus à tuer.
Est-ce que la commande ci-dessous ne pourrait pas marcher ?

Code :

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

system("%systemroot%\\system32\\tskill.exe  word");

[Razielone]

tu peux avoir le PID d'une application dont tu connais le nom avec le code suivant :

Code :

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

1
2
3
4
 
HWND windowHandle = FindWindowW(NULL, windowName.c_str());
DWORD* processID = new DWORD;
GetWindowThreadProcessId(windowHandle, processID);

[Melem]

Malheureusmeent je ne commais pas lme PID du processus à tuer.
Est-ce que la commande ci-dessous ne pourrait pas marcher ?

Code :

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

system("%systemroot%\\system32\\tskill.exe  word");

Si, ça marche. Tu peux même juste écrire "tskill word" (ou word.exe est le processus qu'on veut tuer). Le problème c'est que s'il y a plusieurs instances de l'application lancées, elles seront toutes arrêtées. Si tu veux arrêter juste une seule instance, il faut avoir le pid du processus associé. Le pid est le seul identificateur unique d'un processus. Il y a dans la FAQ un exemple de code qui énumère tous les processus, ce qui permet d'obtenir entre les noms et les pids des différents processus en cours ...

[bacelar]

Je tiens à signaler que Word.exe est un serveur de composants COM out-of-process des plus utilisés et qu'à ce titre, l'assassiner pourra enclencher très probablement des disfonctionnements graves sur l'ensemble des processus tournant sur le système.

[Melem]

Tu parles de winword.exe (MS Word) ? Bien sûr, mais c'est son choix. On l'a déjà assez averti comme ça.

[Mac LAK]

Surtout qu'on peut terminer Word (ou toute application Windows d'ailleurs) proprement en postant un message WM_QUIT dessus... Dans le cas de Word, on peut également gérer le cas de la sauvegarde d'un éventuel fichier via OLE.

S'il y a bien des applications qu'il n'est JAMAIS nécessaire de flinguer dans un contexte d'utilisation normal (= hors bug "réel"), c'est bien les applications Office vu le niveau d'automatisation que l'on peut réaliser avec...

[Melem]

Surtout qu'on peut terminer Word (ou toute application Windows d'ailleurs) proprement en postant un message WM_QUIT dessus...

Euh non, c'est pas propre du tout. Les applications appellent souvent PostQuitMessage (qui poste le message WM_QUIT dans la queue des messages du thread courant) dans le traitement de WM_DESTROY. Envoyer WM_QUIT à une application d'un coup sec, du moins dans un cas tel que celui-ci, c'est très mauvais.

[Mac LAK]

Euh non, c'est pas propre du tout. Les applications appellent souvent PostQuitMessage (qui poste le message WM_QUIT dans la queue des messages du thread courant) dans le traitement de WM_DESTROY. Envoyer WM_QUIT à une application d'un coup sec, du moins dans un cas tel que celui-ci, c'est très mauvais.

Ou WM_CLOSE si tu préfères, c'est pareil... Beaucoup d'applications traitent indifféremment les deux messages, et avec le même résultat : la fermeture propre de l'application.
Et ça reste certes une fermeture un peu plus brutale qu'une demande par OLE, mais pas plus que de cliquer sur la croix rouge de fermeture, et infiniment moins que d'appeler TerminateProcess.

[Melem]

1. WM_CLOSE c'est propre mais ce n'est pas garanti que ça va fermer l'application. Cette dernière aura encore éventuellement une question pertinente () à poser comme : "Êtes-vous sûr de vraiment vouloir quitter ?", etc.

2. Envoyer WM_CLOSE et WM_QUIT, c'est pas du tout pareil. Voici, dans sa variante principale, les grandes étapes de la fermeture d'une application (dans l'ordre chronologique), à partir de WM_CLOSE :

a. Réception de WM_CLOSE
b. Appel de DestroyWindow (dans le traitement de WM_CLOSE)
c. Réception de WM_DESTROY
d. Libération éventuelle de certaines ressources (dans le traitement de WM_DESTROY)
e. PostQuitMessage (dans le traitement de WM_DESTROY)
f. Fin de la boucle des messages (typiquement on se retrouve là dans WinMain)
g. return 0;

Envoyer WM_QUIT depuis l'extérieur, c'est placer brusquement l'application en f., sans l'avoir fait passer par a., b., c., d. et e. (bon le e. on peut l'ignorer ...).

3. Cliquer sur la croix en rouge de fermeture (ce qui va engendrer une série de messages aboutissant à la fin à un WM_CLOSE ...) ou exécuter une commande équivalente (genre fichier > quitter, etc.) n'a jamais été malpropre pour fermer une application.

4. Bien entendu, si l'application est un Automation Server, alors on dispose d'un moyen sûr et très propre pour la fermer : OLE. Malheureusement, ce ne sont pas toutes les applications qui le sont et pour ces dernières, il n'y a rien à faire.

5. Quitte à terminer une appli de manière brutale, je préfère la plus brutale parce qu'au moins ça me donnera l'impression d'être ... puissant . En effet, avec un gentil WM_QUIT, si l'application ne répond plus (du à un quelconque plantage), tu vas vite t'énerver .

[Mac LAK]

4. Bien entendu, si l'application est un Automation Server, alors on dispose d'un moyen sûr et très propre pour la fermer : OLE. Malheureusement, ce ne sont pas toutes les applications qui le sont et pour ces dernières, il n'y a rien à faire.

Mais c'est le cas des applications Office, tu le sais aussi bien que moi.

Cliquer sur la croix rouge, en fonction de l'application, peut très bien être une fermeture crasseuse : je me rappelle notamment d'une application Delphi, que j'avais reprise, pour laquelle ça tuait la fenêtre principale, mais pas l'application qui continuait de tourner derrière... En effet, ça faisait ce qui était demandé : fermer la TForm. Problème, ce n'était PAS la fiche principale de l'application !
Du coup, application plantée et impossible à fermer proprement, sauf à poster "manuellement" un WM_QUIT derrière... Facile à corriger, bien sûr, mais je ne te dis pas le nombre de processus "zombis" qui pouvaient être trouvés sur certaines machines après une journée de taf.

5. Quitte à terminer une appli de manière brutale, je préfère la plus brutale parce qu'au moins ça me donnera l'impression d'être ... puissant . En effet, avec un gentil WM_QUIT, si l'application ne répond plus (du à un quelconque plantage), tu vas vite t'énerver .

En général, quand je veux fermer une application "générique", je passe en trois phases :

• Post d'un WM_CLOSE.
• Au bout d'un certain délai, si l'application est toujours active, post d'un WM_QUIT.
• Si toujours rien, appel de TerminateProcess.

Jusqu'à présent, à part avec un plantage sévère, je ne dépasse jamais la première étape... Et je n'ai pour l'instant jamais eu de pertes de données en phase d'exploitation.
Le délai est variable en fonction de la réactivité connue de l'application, ou 15 secondes par défaut. Souvent, je préviens l'utilisateur avant de flinguer brutalement le processus, on ne sait jamais.
Pour les applications console, j'intercale parfois un appel à GenerateConsoleCtrlEvent avant le TerminateProcess, suivant le cas, mais c'est un peu pénible à utiliser correctement donc je le fais assez rarement au final.
On peut aussi utiliser un CreateRemoteThread qui appelera ExitProcess, mais pareil : ça demande des droits et beaucoup de boulot pour pas grand-chose de plus au final.

A noter que j'applique la même méthode pour les threads : arrêt "prévu" du thread, puis s'il ne répond pas, j'appelle TerminateThread. En dernier recours, s'il est encore actif (cas déjà vécu), je le suspends, je baisse sa priorité, et je libère ses ressources connues.


Bien entendu, si je connais l'application en question, j'agis autrement : soit j'ai un canal de communication connu et permettant l'opération (ex : communication RPC, nœud ICE, application OLE, etc.), soit c'est moi qui écrit l'application et je sais donc exactement quand et comment la fermer depuis l'extérieur (vivent les events nommés).


Pour le côté "puissant", t'as toujours la solution de débrancher la prise aussi. C'est radical, et j'ai même un client qui m'a fait le coup une fois pour "vérifier" si l'application le supportait... L'application l'a supporté, on a pu le vérifier sur les traces de log qui indiquaient un état "stable". Le système d'exploitation, par contre, l'a largement moins bien toléré...

[Melem]

Cliquer sur la croix rouge, en fonction de l'application, peut très bien être une fermeture crasseuse

Oui c'est vrai, je pensais surtout aux applications qui se terminent immédiatement après la fermeture de la fenêtre principale. En tout cas, si fermer la fenêtre principale d'une application ne doit pas immédiatement causer sa fin, il doit y avoir quelque part un moyen "prévu" de la faire réapparaître, en créant un Tray Icon par exemple (ou n'importe quelle autre solution "prévue"). Dans le cas contraire, c'est tout simplement l'application qui est buggé et on peut pas blâmer un utilisateur pour avoir essayé de terminer proprement l'application en fermant la fenêtre principale.

Pour le reste, j'ai jamais dit qu'on ne pouvait jamais terminer une application en lui envoyant WM_QUIT mais seulement que ce n'était pas propre. Cela a été mis en évidence dans mon précédent message. Je peux même ajouter que si une application multithreadée envoie un signal de fin à ses threads lors de la fermeture de sa fenêtre principale par exemple et qu'elle attend la terminaison effective de ces threads avec un délai infini après la boucle des messages alors là, envoyer le message WM_QUIT va faire planter l'application et non la terminer ...