Envoi d'un message à une application démarrée par une autre session utilisateur de Windows

Question

Une application de bureau (créée en Delphi) est lancée par l'utilisateur A. Appelons-la "Instance A".

utilisateur A fait un "utilisateur de commutateur" et les journaux B utilisateur dans.

utilisateur B exécute la même application. Appelons-le « instance B »

Ce que je veux maintenant, est un moyen pour l'instance B pour envoyer des messages à l'instance A.

J'essayé ce qui suit: Instance A écrit sa poignée dans un fichier, donc instance B peut ouvrir ce fichier, lire le handle et l'utiliser pour publier un message dans l'instance A, mais cela ne fonctionne pas. Pour des raisons de sécurité, Windows n'autorise pas un utilisateur à gérer les processus d'un autre utilisateur. Un "mauvais" moyen de faire cela serait d'avoir l'instance A vérifier un fichier particulier ou un emplacement de registre toutes les quelques secondes, donc l'instance B peut écrire quelque chose là-bas et l'instance A l'obtiendra ... mais c'est de toute évidence un lourd et unelegan t solution. Au lieu de cela, j'ai besoin d'un moyen pour que l'instance B de l'utilisateur B envoie un message inoffensif à l'instance A de l'utilisateur A, après quoi l'instance A se réveille et décide quoi faire à ce propos.

Merci pour vos suggestions!

Answer 1

Vous ne pouvez pas utiliser SendMessage, PostMessage et des fonctions similaires, car les instances d'application de différentes sessions utilisateur ne sont pas disponibles pour votre application. Ce que vous pouvez utiliser sont des tuyaux nommés, des sémaphores etc. dans l'espace de noms global (c'est-à-dire que les noms sont préfixés par "Global"). Ensuite, créez un thread distinct dans votre application qui, par exemple, dort jusqu'à ce qu'un "signal" de l'un d'entre eux arrive et notifie la fenêtre principale en conséquence. Pour enregistrer les ressources, utilisez WTSRegisterSessionNotification pour recevoir une notification lorsque le basculement de session se produit et créez le thread uniquement à ce stade.

Plus d'informations ici: http://support.microsoft.com/kb/310153 et ici: http://msdn.microsoft.com/en-us/library/ms997634.aspx

Answer 2

N'est-ce pas essentiellement le même problème que d'avoir un service Windows exécuté sous un compte système et d'avoir une instance d'utilisateur d'une application qui communique avec lui? Alors peut-être que vous devriez google pour la communication interprocessus (pipes nommées, etc.). Vous pouvez également utiliser UDP ou TCP/IP, mais je suppose que l'utilisation de canaux nommés est préférable pour la communication "locale" (bien que je ne l'ai jamais fait vraiment).

Lecture here sur les canaux nommés sur MSDN.