🚀 go-pugleaf

"Paul" <camrad@internode.on.net> wrote in message
news:46a0a522$1@newsgroups.borland.com...

> Each of the above is started with
> if (CreateProcess(...
<snip>

Which means that each process is going to run in the context of the user
account that the service is running it.  By default, that is the SYSTEM
account.  Also, unless you are filling in the lpDesktop member of the
STARTUPINFO structure, then each process is going to run in the context of
the service's workstation as well, which is hidden and does not have access
to the workstation that the user logs into.

> Using Windows Messaging
> - RegisterWindowMessage
> - EnumWindows to get the required handle
> - then PostMessage

That won't work in a service unless you first connect it to the user's
desktop via SetThreadDesktop().  Same thing with spawned processes - they
must be running in the same desktop that the target window is running in, or
else EnumWindows() and PostMessage() will fail to locate it.

> At this point EnumWindows can find the required handle from
> the process id. There may or may not be a user logged on at
> this point - it makes no difference to the following outcomes.

Yes, it does make a difference.

> EnumWindows does not have this process id in the list returned
> when trying to get the new window handle to use, so no messaging
> is possible withou a valid handle.

Every time a process is restarted, the other apps will have to rescan the
active windows in order to get the new ID.  Alternative, assuming the
guardian is running in the same desktop as the other processes, it could
simply broadcast a message containing the old and new IDs, and the processes
can then update themselves accordingly.

> Manually entering the windows handle of the restarted process
> into the guardian and using PostMessage - The restarted process
> does not see the message.

That suggests to me that the guardian is not actually running in the same
desktop afterall, as window messages cannot pass across desktop boundaries.


Gambit