IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Windows Discussion :

Comment propager un signal Kill d'un process vers un autre sous windows ?


Sujet :

Windows

  1. #1
    Membre du Club Avatar de masterx_goldman
    Inscrit en
    Mai 2008
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 164
    Points : 51
    Points
    51
    Par défaut Comment propager un signal Kill d'un process vers un autre sous windows ?
    Bonjour tout le monde,

    J'ai 3 Processus P1, P2 et P3:
    * P1: service windows prêt que j'utilise pour lancer P2(c'est pas le mien ce service, je peux m'en servir mais je peux pas modifier son code. Pour lancer P2, je fais une petite config dans la clé de registre).
    * P2, P3 : deux processus dont le code est le mien, donc je peux y agir et modifier.
    Le but c'est d'assurer :
    a)un lancement en cascade(P1 lance P2 , P2 lance P3 , ça je l'ai fait déja : quand P2 se lance , il lance P3 avec CreateProcess() )
    b)un arrêt en cascade(arrêt de P1 => arrêt de P2 => arrêt de P3 )( ça je vois pas comment le faire )

    Quand P1 s'arrête il tue P2 par un kill ( je pense .., je suis pas sûr ) donc P3 ne reçoit rien de la part de P2 et par suite reste en exécution.

    Alors, y'a une solution qui consiste à faire une vérification périodique dans P3 de l'état d'exécution de P2 et faire un exit s'il est arrêté ..
    Mais comme vous savez le problème de consommation de vérification périodique et aussi le problème de choix de la période ...

    Alors est ce qu'il n'y a pas un autre moyen plus propre pour faire ça ?

    Merci pour vos réponses

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Les signaux POSIX (kill) sous Windows, même pas en rêve.

    P2 et P3 sont-ils aux aussi des services Windows ?

    Sinon, le plus simple est de faire des attentes sur handler de processus dans des threads dédiés.

    En clair, cela dépend du bricolage de P1, qui devrait être documenté d'ailleurs

  3. #3
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    L'arrêt d'un service sous Windows, tout comme les dépendances entre services, sont des opérations "propres", et non pas des kill bourrins...

    Voir MSDN pour l'API de gestion des services.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  4. #4
    Membre du Club Avatar de masterx_goldman
    Inscrit en
    Mai 2008
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 164
    Points : 51
    Points
    51
    Par défaut
    Citation Envoyé par bacelar Voir le message
    Les signaux POSIX (kill) sous Windows, même pas en rêve.
    Y'a pas un équivalent en Win32 ?!

    P2 et P3 sont-ils aux aussi des services Windows ?
    Non, se sont des processus "ordinaires" .
    Sinon, le plus simple est de faire des attentes sur handler de processus dans des threads dédiés.
    Un exit(-1) (Après une attente sur le handler )dans un thread crée par P3 dédié à contrôler l'état de P2 engendre l'arrêt de P3 ? Je pense oui, mais je suis pas sûr ( test en cours ..)
    En clair, cela dépend du bricolage de P1, qui devrait être documenté d'ailleurs
    La doc n'est pas précise en ce point malheureusement.

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Y'a pas un équivalent en Win32 ?!
    La dernière fois, c'était en Win16 et c'était une usine à gaz sur le point d'exploser. C'est peut-être faisable dans le sous-système POSIX mais pas dans le sous-système Win32.

    Un exit(-1) (Après une attente sur le handler )dans un thread crée par P3 dédié à contrôler l'état de P2 engendre l'arrêt de P3 ? Je pense oui, mais je suis pas sûr ( test en cours ..)
    Heu, là c'est vraiment gore comme autodestruction. Le plus polie est soit envoyer de message pour une application graphique soit le déclanchement d'un objet Kernel "Event".

    La doc n'est pas précise en ce point malheureusement.
    Envoies le lien, on décortiquera.

    Mais, dans l'absolu, lancer des programmes non Service-Windows Aware à partir d'un service Windows, c'est s'exposé à de grosse déconvenue (sécurité, debugging etc...)

  6. #6
    Membre du Club Avatar de masterx_goldman
    Inscrit en
    Mai 2008
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 164
    Points : 51
    Points
    51
    Par défaut
    Citation Envoyé par masterx_goldman Voir le message
    Un exit(-1) (Après une attente sur le handler )dans un thread crée par P3 dédié à contrôler l'état de P2 engendre l'arrêt de P3 ? Je pense oui, mais je suis pas sûr ( test en cours ..)
    Pour info, j'ai essayé le exit(-1) dans le code du thread => on sort de tout le programme
    ça m'arrange dans ce cas

    maintenant, je pense que je dois utiliser un WaitForSingleObject mais je sais pas comment m'en servir dans ce cas
    Voilà comment je vois le code pour le moment, mais je sais pas si le Handle obtenu sur le processus P2 va être mis à l'état SIGNALED quand celui ci s'arrête brusquement ou bien il va être dans un autre état..
    Bon, voici un exemple de code, je sais pas s'il va être suffisant ou pas , merci de me le corriger

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    UINT __cdecl ControlerThread( LPVOID pParameters )
    {
    
    DWORD processID=GetPidByName("P2.exe");// j'obtient le PID du process P2 par une fonction prédéfinie  GetPidByName
    HANDLE hP2=OpenProcess( PROCESS_QUERY_INFORMATION ,FALSE, processID );
    WaitForSingleObject(hP2,INFINITE);	
    exit(-1);				
    return 0;
    }

  7. #7
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par masterx_goldman Voir le message
    Y'a pas un équivalent en Win32 ?!
    Cela oscille entre la messagerie Windows classique et le contrôle par l'API. En tout cas, les signaux n'ont aucun sens sous Windows, il y a d'autres méthodes pour contrôler les processus.

    Pour le reste, tu peux demander la terminaison de tes processus "proprement" au niveau du gestionnaire d'arrêt de ton service (essaie toujours de poster un WM_QUIT ou autre message, sait-on jamais...), ce sera toujours plus propre que de flinguer les processus façon sauvage.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  8. #8
    Membre du Club Avatar de masterx_goldman
    Inscrit en
    Mai 2008
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 164
    Points : 51
    Points
    51
    Par défaut
    Citation Envoyé par bacelar Voir le message
    La dernière fois, c'était en Win16 et c'était une usine à gaz sur le point d'exploser. C'est peut-être faisable dans le sous-système POSIX mais pas dans le sous-système Win32.
    Dans ce cas, comment on paut arrêter un processus windows ?

    Heu, là c'est vraiment gore comme autodestruction. Le plus polie est soit envoyer de message pour une application graphique soit le déclanchement d'un objet Kernel "Event".
    J'ai aucun truc graphique, le Event me parait plus convenable.
    Où dois je déclarer l'Event ? et comment le thread lancé par P3 peut s'en servir ?

    Envoies le lien, on décortiquera.
    C'est pas docuementé sur le net, c'est développé par une entreprise et la doc fournie est trop superficielle ...
    Mais, dans l'absolu, lancer des programmes non Service-Windows Aware à partir d'un service Windows, c'est s'exposé à de grosse déconvenue (sécurité, debugging etc...)
    J'ai pas trop compris ça

  9. #9
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Aussi bien sous POSIX que sous Windows, un vrai kill est indétectable, un processus est donc incapable de le propager lui-même à ses fils.

    Sous un Windows récent, tu peux faire un "job object" contenant un processus et ses descendants, et killer le job en un coup. C'est sale (aussi sale que killer un processus, en fait), mais ça a le mérite de marcher.

    Mais si tu veux faire les choses bien, tu dois envoyer au processus P2 un ordre de se suicider (par un moyen restant à définir), qui le relaiera à P3 (probablement par le même moyen) avant de s'exécuter.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  10. #10
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par masterx_goldman Voir le message
    Dans ce cas, comment on paut arrêter un processus windows ?
    Tu le lui demandes gentiment, via un message Windows (WM_CLOSE, WM_QUIT, etc.) s'il possède une boucle de message, ou tu utilises l'API dédiée pour un service.

    Si ton programme ne possède ni l'un, ni l'autre, alors il n'est pas censé être "arrêtable" depuis l'extérieur... Ce qui peut avoir deux causes :
    • Mauvaise connaissance de Windows et non-respect des règles basiques d'implémentation, donc mauvais programme.
    • Programme court et/ou critique ne devant JAMAIS être arrêté par une application extérieure, donc pas touche.
    Sinon, bien sûr, tu as TerminateProcess pour le kill pur et dur : c'est très très crade, totalement impossible à intercepter, et tu risques pas mal de soucis de stabilité / fuites mémoire, mais bon...

    Citation Envoyé par masterx_goldman Voir le message
    J'ai aucun truc graphique, le Event me parait plus convenable.
    Où dois je déclarer l'Event ? et comment le thread lancé par P3 peut s'en servir ?
    Tu crée l'event (nommé, donc global sur le système) dans le processus "maître", tu le signales depuis ce même processus, et côté P3 ton thread se contente d'attendre cet event. Une fois qu'il est signalé, c'est à toi de propager l'information depuis le thread afin d'arrêter proprement ton processus (nettoyage des allocations + arrêt propre du thread principal).

    Citation Envoyé par masterx_goldman Voir le message
    J'ai pas trop compris ça
    Un service n'est PAS un processus ordinaire, c'est un service. Un daemon sous *nix, si tu préfères. Il ne se contrôle pas comme un processus classique, n'a pas les mêmes droits ni les mêmes privilèges.
    Lancer un processus "normal" depuis un service, surtout si le processus ne s'attends PAS à être lancé autrement que par l'utilisateur, c'est s'exposer à de gros risques (surtout si le service lance tout ça avec des droits d'administrateur...).
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  11. #11
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Avec le Exit(-1) dans un thread auxiliaire, vous allez au devant de graves problèmes. L'Exit(-1) va stopper net tous les threads de votre programme, y compris un éventuel thread en train d'écrire dans un fichier de configuration qui sera mal formaté et vous fera planter le programme au prochain redémarrage.
    Enfin bref, ne jamais arrêter un programme sauvagement mais toujours en ordre. Votre thread auxiliaire prévient le thread principal de votre application que c'est le moment de plier bagage. Pour cela, le plus simple est de "Setter" un Event partagé entre le thread principal et le thread auxiliaire. Après avoir "Setter" cet Event, le thread auxiliaire s'arrête en sortant de la fonction par un simple "return" Le thread principal vérifie régulièrement l'état de l'Event et sort proprement en arrêtant d'éventuels autres threads auxiliaires (par une demande, pas à la sauvage, cette demande, cela peut être une paire d'Event, un pour demander l'arrêt du thread auxiliaire, l'autre pour acquitter le fait que le thread auxiliaire c'est terminé de manière ordonné (vous pouvez avantageusement remplacé le deuxième Event par l'handler sur le thread auxiliaire si vous avez pris la peine de le stocker quelque part) ).

    non Service-Windows Aware
    Le fait d'être lancé par un service Windows veux dire qu'il sera vraisemblablement lancé dans le contexte de sécurité (WorkStation) des services qui n'ont pas le droit "d'écrire" sur l'écran de la personne connectée, entre autre.
    Donc, le plus simple c'est de faire des services et pas des programmes "normaux".

    C'est pas docuementé sur le net, c'est développé par une entreprise et la doc fournie est trop superficielle ...
    Cette documentation fourni bien le moyen par lequel P1 demande à P2 de se suicidé. Si P1 tue P2, laissez tomber cette cochonnerie et fait des services avec dépendances qui seront directement et correctement gérées par l'OS.

  12. #12
    Membre du Club Avatar de masterx_goldman
    Inscrit en
    Mai 2008
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 164
    Points : 51
    Points
    51
    Par défaut
    Citation Envoyé par bacelar Voir le message
    Avec le Exit(-1) dans un thread auxiliaire, vous allez au devant de graves problèmes. L'Exit(-1) va stopper net tous les threads de votre programme, y compris un éventuel thread en train d'écrire dans un fichier de configuration qui sera mal formaté et vous fera planter le programme au prochain redémarrage.
    Oui je me rends compte maintenant du danger posé dans ce cas
    Votre thread auxiliaire prévient le thread principal de votre application que c'est le moment de plier bagage. Pour cela, le plus simple est de "Setter" un Event partagé entre le thread principal et le thread auxiliaire. Après avoir "Setter" cet Event, le thread auxiliaire s'arrête en sortant de la fonction par un simple "return"
    Oui ça je l'ai déja, j'ai un évennement de terminaison hTerminateEvent déclaré dans le processus principal et les autres threads sont dans une boucle inifinie d'attente en état waitForMultipleObjects() et font un return dans le cas où le event hTerminate est signalé.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    WaitForMultipleObjects(3, Handles, FALSE, INFINITE);// Handles est un tableau de Handle ..
    Le thread principal vérifie régulièrement l'état de l'Event et sort proprement en arrêtant d'éventuels autres threads auxiliaires (par une demande, pas à la sauvage, cette demande, cela peut être une paire d'Event, un pour demander l'arrêt du thread auxiliaire, l'autre pour acquitter le fait que le thread auxiliaire c'est terminé de manière ordonné (vous pouvez avantageusement remplacé le deuxième Event par l'handler sur le thread auxiliaire si vous avez pris la peine de le stocker quelque part) ).
    Ok, bonne idée, je vais voir comment faire ça ..


    Donc, le plus simple c'est de faire des services et pas des programmes "normaux".
    Oui, tu as raison sauf que j'ai pas le droit à faire des services windows pour respecter les règles de fonctionnement des modules dans le produit que je suis entrain d'améliorer >_<

  13. #13
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Quel architecte logiciel est assez stupide pour imposer des programmes "normaux" lancés par un service Windows ?

  14. #14
    Membre du Club Avatar de masterx_goldman
    Inscrit en
    Mai 2008
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 164
    Points : 51
    Points
    51
    Par défaut
    Maintenant, une question très importante:
    Je reformule les données:
    J'ai :
    *P1(service windows)
    *P2 et P3 : 2 processus ordinaires
    * th_i :thread lancé par P3
    * thAux: thread auxiliaire qui contrôle l'état de P2 ( lancé ou arrêté )

    Comment faire pour faire attendre thAux sur un WaitForSingleObject() pour qu'il puisse retourner quand le processus P2 se termine ?

    Comme tentative de début j'ai essayé d'obtenir un HANDLE sur P2 par OpenProcess() puis un WaitForSingleObject() mais le thread n'attend pas sur ce Wait .. ( c'est débil comme essai mais c'est dans ce sens que je veux faire les choses : thAux Attend la sortie de P2 et puis signale ça à son père P3 )

    Merci pour tout type d'aide

  15. #15
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Ça devrait pourtant marcher: Si tu as le droit SYNCHRONIZE sur le processus, tu dois pouvoir attendre qu'il se termine avec WaitForSingleObject()...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  16. #16
    Membre du Club Avatar de masterx_goldman
    Inscrit en
    Mai 2008
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 164
    Points : 51
    Points
    51
    Par défaut
    Citation Envoyé par Médinoc Voir le message
    Ça devrait pourtant marcher: Si tu as le droit SYNCHRONIZE sur le processus, tu dois pouvoir attendre qu'il se termine avec WaitForSingleObject()...
    ça veut dire quoi ce droit et comment je peux vérifier si je l'ai ou pas ?

    Rq: Je suis sous compte Administrateur

  17. #17
    Expert éminent sénior
    Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2005
    Messages
    27 369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2005
    Messages : 27 369
    Points : 41 518
    Points
    41 518
    Par défaut
    Généralement, tu l'as.
    Par contre, il faut penser à le demander lors de l'appel à OpenProcess() ou équivalent...
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  18. #18
    Membre du Club Avatar de masterx_goldman
    Inscrit en
    Mai 2008
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 164
    Points : 51
    Points
    51
    Par défaut
    Citation Envoyé par Médinoc Voir le message
    Ça devrait pourtant marcher: Si tu as le droit SYNCHRONIZE sur le processus, tu dois pouvoir attendre qu'il se termine avec WaitForSingleObject()...
    héhé ça marche avec SYNCHRONIZE , en faite mois j'avais mis PROCESS_QUERY_INFORMATION qui vise obntenir des info sur ce process or qu'il fallait mettre un SYNCHRONIZE pour se synchroniser avec l'état du process P2
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    UINT __cdecl ControlerThread( LPVOID pParameters )
    {
    
    DWORD processID=GetPidByName("P2.exe");// j'obtient le PID du process P2 par une fonction prédéfinie  GetPidByName
    HANDLE hP2=OpenProcess(SYNCHRONIZE   ,FALSE, processID );
    WaitForSingleObject(hP2,INFINITE);				
    return 0;
    }

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 2
    Dernier message: 27/08/2010, 00h07
  2. Réponses: 3
    Dernier message: 14/09/2009, 11h56
  3. Réponses: 4
    Dernier message: 25/10/2007, 15h37
  4. Comment transférer une ligne d'une feuille Excel vers une autre
    Par iboulaye1980 dans le forum Macros et VBA Excel
    Réponses: 4
    Dernier message: 28/05/2007, 11h32
  5. Réponses: 5
    Dernier message: 04/05/2006, 10h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo