What desktop am I running on?

[Mark J. Hogan]

How can I detect what Desktop I am running on (where "I" is a program)?

What I mean by this is: is the program running on the "Default" desktop
or the services' desktop? Is this a process that is interactive with the
user or hidden in the background?

Any ideas?

Thanks,
--
Mark J. Hogan
________________________________________________
Senior Consultant
System Management Technologies, Inc.
Web Page: http://www.smtechnologies.com

[Axel Köster]

Mark J. Hogan wrote:

> How can I detect what Desktop I am running on (where "I" is a program)?
>
> What I mean by this is: is the program running on the "Default" desktop
> or the services' desktop? Is this a process that is interactive with the
> user or hidden in the background?

Hello Mark,

you get the handle to the desktop that receives user input with
OpenInputDesktop().

The following lines of code should solve your problem:

HDESK hdesk;

hdesk = OpenInputDesktop( .. , .. , .. );
if( hdesk )
{
if( hdesk == GetThreadDesktop( GetCurrentThreadId()))
// your thread run on the input desktop
else
// your thread don't run on the input desktop
CloseDesktop( hdesk );
}

Regards,
Axel

[Mark J. Hogan]

Axel,

Thanks for the reply. You were close to a solution, but this won't work.
But wait, you led me on to a solution.

First, comparing handles will NOT work because you can get a different
handle every time you call these functions.

So, I got the handles from OpenInputDesktop and GetThreadDesktop and then
called GetUserObjectInformation for each handle. Then I compared the Names!
For a interactive process, the names are both Default. For a background
process, OpenInputDesktop fails with error 1 but GetThreadDesktop works and
GetUserObjectInformation returns "Defaut". So I figure if both Names are
equal, then it is interactive. If the call fails or the names are not
equal, then it is a background process. Here is the
GetUserObjectInformation call.

GetUserObjectInformation(
hDesk, // handle to object
UOI_NAME, // type of information to retrieve
szInputName, // information buffer
260, // size of the buffer
&dwLengthNeeded // receives required buffer size

Thanks,
Mark

[Daniel Lohmann]

On Wed, 9 Feb 2000 11:03:55 -0600, "Mark J. Hogan"
<hog...@smtechnologies.com> wrote:

>Axel,
>
>Thanks for the reply. You were close to a solution, but this won't work.
>But wait, you led me on to a solution.
>
>First, comparing handles will NOT work because you can get a different
>handle every time you call these functions.
>
>So, I got the handles from OpenInputDesktop and GetThreadDesktop and then
>called GetUserObjectInformation for each handle. Then I compared the Names!
>For a interactive process, the names are both Default. For a background
>process, OpenInputDesktop fails with error 1 but GetThreadDesktop works and
>GetUserObjectInformation returns "Defaut". So I figure if both Names are
>equal, then it is interactive. If the call fails or the names are not
>equal, then it is a background process.

What is the exact meaning of the term "background process"?

If your process runs as Service _without_ beeing allowed to interact
with the desktop. I guess this is what you call a background process.

The OpenInputDesktop() API returns a handle to the Desktop currently
receiving user input. This has _not_ to be the default desktop, since
there are multi-desktop tools available (I have written one, you may
check it out at http://www.netexec.de ), so your algorithm works not
correctly in all cases. Also, if no user has been logged in, I suppose
the "Winlogon" Desktop will be returned as input desktop.

Important is the following part of the OpenInputDesktop() docs:

"The calling process must have an associated window station, either
assigned by the system at process creation time or set by
SetProcessWindowStation. The window station associated with the
calling process must be capable of receiving input."

In other words: OpenInputDesktop() fails if the process's
windowstation is not "WinSta0", which is the only interactive
windowstation (capable of receiving input). If your service runs as
background process (not being allowed to interact with the user) the
system creates an own windowstation for it.

So I suggest you should check out the "GetProcessWindowStation()" Api
and check if it is "WinSta0" to decide between interactive /
background processes.

Daniel