Discussion :

[=JBO=]

Bonjour,

Sur un PC (Windows 2000 serveur) où s'exécutent plusieurs sessions (TSE), je voudrais qu'une fenêtre d'une session soit accessible à partir d'une autre session, notamment pour lui envoyer des messages Windows, lire son "Caption", etc.

J'ai essayé d'utiliser les API SendMessage, GetWindowText mais sans succès.

Est-ce un problème de sécurité ?
Quelqu'un a-t-il un idée ?

Toute aide sera la bienvenue, merci !
_

[Mac LAK]

Sécurité à priori, vu qu'en temps normal, tu n'as pas à toucher aux sessions des autres utilisateurs...

Tu peux toutefois listes les processus tournant sur la machine quels que soient les utilisateurs (et donc les sessions), mais de là à autoriser l'envoi de messages... Entre deux processus "collaborant" entre eux (via mémoire partagée ou sockets par exemple), OK, pas trop de soucis.

Mais aller intercepter une application qui compte avoir "la paix" dans sa propre session depuis une autre session, je ne sais pas si c'est possible. En tout cas, ça ne m'étonnerait pas que ce soit impossible.

[=JBO=]

Merci pour ta réponse.

Sécurité à priori, vu qu'en temps normal, tu n'as pas à toucher aux sessions des autres utilisateurs...
[...]
Mais aller intercepter une application qui compte avoir "la paix" dans sa propre session depuis une autre session, je ne sais pas si c'est possible. En tout cas, ça ne m'étonnerait pas que ce soit impossible.

En l'occurrence, je suis le développeur des applications en question.
Je souhaite qu'une de mes applications "pseudo-serveur" soit accessible facilement par mes autres applications "pseudo-clients".

Pourquoi se compliquer l'existence en utilisant le partage mémoire et autres ?...
...alors que l'exécution de SendMessage, GetWindowCaption et consort pourraient être simplement sécurisée.

Il n'y aurait que BroadcastSystemMessage qui puisse envoyer un message vers les fenêtres des différentes sessions (diffusion) ?
_

[Mac LAK]

En l'occurrence, je suis le développeur des applications en question.

Bon, déjà, t'es pas direct la tête dans le mur, c'est déjà ça !

Pourquoi se compliquer l'existence en utilisant le partage mémoire et autres ?...

Parce que cela peut être rendu global au système, hors de toute notion de session et/ou de sécurité... Et donc, accessible par tous les processus de toutes les sessions. En effet, tu as un attribut de sécurité qui est en paramètre de la création de mémoire partagée.

...alors que l'exécution de SendMessage, GetWindowCaption et consort pourraient être simplement sécurisée.

Justement pas : tu imagines les failles potentielles ??

Il n'y aurait que BroadcastSystemMessage qui puisse envoyer un message vers les fenêtres des différentes sessions (diffusion) ?
_

Vu que PostThreadMessage est également limité au bureau courant, je pense que oui... Ou de la mémoire partagée, ou encore des sockets sur la boucle locale.

[=JBO=]

Effectivement, je vais devoir m'y prendre autrement.

Alors pour information (et sous réserve d'une compréhension correcte ):

* Un système Windows peut héberger plusieurs objets "Windows Station", sous le contrôle du Session Manager.

* Un objet "Window Station" peut posséder plusieurs objets "Desktop".
Par exemple, quand un utilisateur démarre une session, il travaille via un objet "Windows Station" associé à WinLogon, et qui contient 3 Desktops:
_ a. Winlogon desktop
_ b. Application desktop
_ c. Screen-saver desktop

* Un objet Desktop possède sa propre collection d'objets "Windows", son propre presse-papiers et sa propre gestion de Hooks.

Par conséquent, les API qui concernent les objets "Windows" ne peuvent agir que sur le Desktop auquel appartient le processus (thread) qui y fait appel.


Autres informations:

* Chaque service est associé à un objet "Windows Station" et un objet "Desktop"

* L'API SetThreadDesktop() permet à un thread de travailler dans le contexte d'un objet Desktop arbitraire, et donc d'énumérer les objets Windows ou encore envoyer des messages dans un Desktop autre que celui d'origine.
Mais d'après ce que je lis sur le web (notamment dans cette conversion: EnumThreadWindows() to threads of another logon-session) son utilisation est restreinte car le processus qui fait appel à SetThreadDesktop() ne doit pas encore avoir créé d'objet "Windows".
_

[Mac LAK]

Le plus simple pourrait alors être des sockets sur localhost (127.0.0.1, donc) : ça, c'est certain, ça marche même si ce n'est pas forcément le plus pratique du monde... Quoi que, encore, via de l'UDP, tu peux limiter un peu la casse.

Reste à voir pour la mémoire partagée, si elle est capable de franchir la barrière des sessions ou pas...


Bon courage, en tout cas, je crois que là tu as trouvé un bon casse-tête.