Prev: Getting subnet mask with GetAdaptersAddresses
Next: CreateProcessAsUser from CredProv on Vista/Longhorn Server
From: Nadav on 2 Nov 2006 12:13
Hi,

Prolog:
1. I am writing a DirectShow/DirectX oriented application.
2. This application has no real interaction with DirectShow/DirectX object
other then enumerating available video & audio capture sources and presenting
the capture properties.
3. This application is used to remotely manage our product on customer sites.
4. For remote management and customer support we use Microsoft's remote
desktop application.
5. DirectX / Direct show is NOT supported by remote desktop.
6. Capture device enumeration fail to show all devices while executing
within a remote desktop session
7. Capture device enumeration DOESN'T fail when executed by a services
started through a remote desktop session.

Were am I getting to?
**********************
Taking the above in mind ( and paragraph 7 especially ), if the service
could present a GUI on the remote desktop session the problem would have been
resolved, this can be done by strictly specifying the windows station and
desktop to be used by the service, following is what I was doing to achieve
that:
a. I have created a Win32 launcher application that starts a custom service
b. The launcher application is intended to be launched from the remote
desktop session.
c. Prior to starting the service the launcher application queries for the
windows station and desktop it uses ( expected to be the desktop and stations
associated with the remote desktop session from which it was executed ).
d. The Application start the service providing it with the station\desktop
names as startup arguments.
e. The service starts ( as SYSTEM account ) and create ( using CreateProcess
) the management application ( the same application referred to at the
'Prolog' ) setting STARTUPINFO::lpDesktop to the station\desktop pair
extracted from the remote desktop session by the launcher application.
f. The Management application starts with SYSTEM privileges ( as it was
created by the service ), however the GUI of the application is NOT created
on the remote desktop session, rather, it is created on the default
station\desktop pair ( WinSta0\Desktop ).
g. Inspecting the station\desktop queried by the launcher application on [d]
I can see that the default station\desktop ( WinSta0\Desktop ) were extracted
and NOT the remote sessions as expected.

Why does this happen?
Why can't I create a process whose GUI will be presented on the Remote
desktop session while it is possible to create the same process ( with SYSTEM
privileges ) whose desktop is presented on the default station\desktop ?
How can I get a reference to the remote desktop session station\desktop pair ?

Any help would be appreciated.

--
Nadav
http://www.sophin.com

--
Nadav
http://www.sophin.com
From: Ivan Brugiolo [MSFT] on 2 Nov 2006 13:07
Let me clarify some concepts first:
The entire video stack is sessionized.
When you talk about windowstation\desktop,
you are always speaking about 2 dimension of a 3 dimensional space.

The system works this way:
Session X is attached to a terminal.
A terminal is the logical collction of input/HID devices and display
drivers.
When you TS into a machine, you attach an existing session (or a new
session)
to the remote terminal, and, the `glass` or `physical` terminal
is attached to a temporary session.

In your case, when you TS to a machine, you may connect to session #0,
that, in certain legacy operative system is sometimes incidentally
shared by the services, or, you may connect to session #x, (with x != 0).
In any case, the "physical terminal" would be connected to
a session that is NOT the one you are using in mstsc.exe.

That means that video hardware acceleration (and video capture / video
output)
is available only to the Winlogon.exe and csrss.exe processes
that runs in the session attached to the physical console.

To solve your problem, you need to have your applications always running
in the session attached at the `glass termninal`, and, from ony other
session,
you need to communicate with those applications, and, gather data from
there.

Now, this is easy done in a Server SKU, where you have 2 floating session.
You can always "lock" the session attached to the glass terminal in such a
way
that nothing interfears, and, in the second remote session you can "control"
the physical terminal.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
news:2CCA5E63-14CA-4F09-BA4F-90686230F82B(a)microsoft.com...
> Hi,
>
> Prolog:
> 1. I am writing a DirectShow/DirectX oriented application.
> 2. This application has no real interaction with DirectShow/DirectX object
> other then enumerating available video & audio capture sources and
> presenting
> the capture properties.
> 3. This application is used to remotely manage our product on customer
> sites.
> 4. For remote management and customer support we use Microsoft's remote
> desktop application.
> 5. DirectX / Direct show is NOT supported by remote desktop.
> 6. Capture device enumeration fail to show all devices while executing
> within a remote desktop session
> 7. Capture device enumeration DOESN'T fail when executed by a services
> started through a remote desktop session.
>
> Were am I getting to?
> **********************
> Taking the above in mind ( and paragraph 7 especially ), if the service
> could present a GUI on the remote desktop session the problem would have
> been
> resolved, this can be done by strictly specifying the windows station and
> desktop to be used by the service, following is what I was doing to
> achieve
> that:
> a. I have created a Win32 launcher application that starts a custom
> service
> b. The launcher application is intended to be launched from the remote
> desktop session.
> c. Prior to starting the service the launcher application queries for the
> windows station and desktop it uses ( expected to be the desktop and
> stations
> associated with the remote desktop session from which it was executed ).
> d. The Application start the service providing it with the station\desktop
> names as startup arguments.
> e. The service starts ( as SYSTEM account ) and create ( using
> CreateProcess
> ) the management application ( the same application referred to at the
> 'Prolog' ) setting STARTUPINFO::lpDesktop to the station\desktop pair
> extracted from the remote desktop session by the launcher application.
> f. The Management application starts with SYSTEM privileges ( as it was
> created by the service ), however the GUI of the application is NOT
> created
> on the remote desktop session, rather, it is created on the default
> station\desktop pair ( WinSta0\Desktop ).
> g. Inspecting the station\desktop queried by the launcher application on
> [d]
> I can see that the default station\desktop ( WinSta0\Desktop ) were
> extracted
> and NOT the remote sessions as expected.
>
> Why does this happen?
> Why can't I create a process whose GUI will be presented on the Remote
> desktop session while it is possible to create the same process ( with
> SYSTEM
> privileges ) whose desktop is presented on the default station\desktop ?
> How can I get a reference to the remote desktop session station\desktop
> pair ?
>
> Any help would be appreciated.
>
> --
> Nadav
> http://www.sophin.com
>
> --
> Nadav
> http://www.sophin.com


From: Nadav on 3 Nov 2006 07:26
Hi Ivan,

Thanks for your immediate response, there are some points I wish to clarify:
How can I connect to the 'glass termninal' ? My application is launched from
the remote desktop session, the station\desktop used are the ones extracted
from that session, which, according to what you say doesn't really represent
the remote session desktop, to be able to present GUI on the remote desktop
session I have to use the 'glass termninal', BUT, how can I get the
station\desktop of the 'glass termninal' ????

--
Nadav
http://www.sophin.com


"Ivan Brugiolo [MSFT]" wrote:

> Let me clarify some concepts first:
> The entire video stack is sessionized.
> When you talk about windowstation\desktop,
> you are always speaking about 2 dimension of a 3 dimensional space.
>
> The system works this way:
> Session X is attached to a terminal.
> A terminal is the logical collction of input/HID devices and display
> drivers.
> When you TS into a machine, you attach an existing session (or a new
> session)
> to the remote terminal, and, the `glass` or `physical` terminal
> is attached to a temporary session.
>
> In your case, when you TS to a machine, you may connect to session #0,
> that, in certain legacy operative system is sometimes incidentally
> shared by the services, or, you may connect to session #x, (with x != 0).
> In any case, the "physical terminal" would be connected to
> a session that is NOT the one you are using in mstsc.exe.
>
> That means that video hardware acceleration (and video capture / video
> output)
> is available only to the Winlogon.exe and csrss.exe processes
> that runs in the session attached to the physical console.
>
> To solve your problem, you need to have your applications always running
> in the session attached at the `glass termninal`, and, from ony other
> session,
> you need to communicate with those applications, and, gather data from
> there.
>
> Now, this is easy done in a Server SKU, where you have 2 floating session.
> You can always "lock" the session attached to the glass terminal in such a
> way
> that nothing interfears, and, in the second remote session you can "control"
> the physical terminal.
>
> --
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Nadav" <Nadav(a)discussions.microsoft.com> wrote in message
> news:2CCA5E63-14CA-4F09-BA4F-90686230F82B(a)microsoft.com...
> > Hi,
> >
> > Prolog:
> > 1. I am writing a DirectShow/DirectX oriented application.
> > 2. This application has no real interaction with DirectShow/DirectX object
> > other then enumerating available video & audio capture sources and
> > presenting
> > the capture properties.
> > 3. This application is used to remotely manage our product on customer
> > sites.
> > 4. For remote management and customer support we use Microsoft's remote
> > desktop application.
> > 5. DirectX / Direct show is NOT supported by remote desktop.
> > 6. Capture device enumeration fail to show all devices while executing
> > within a remote desktop session
> > 7. Capture device enumeration DOESN'T fail when executed by a services
> > started through a remote desktop session.
> >
> > Were am I getting to?
> > **********************
> > Taking the above in mind ( and paragraph 7 especially ), if the service
> > could present a GUI on the remote desktop session the problem would have
> > been
> > resolved, this can be done by strictly specifying the windows station and
> > desktop to be used by the service, following is what I was doing to
> > achieve
> > that:
> > a. I have created a Win32 launcher application that starts a custom
> > service
> > b. The launcher application is intended to be launched from the remote
> > desktop session.
> > c. Prior to starting the service the launcher application queries for the
> > windows station and desktop it uses ( expected to be the desktop and
> > stations
> > associated with the remote desktop session from which it was executed ).
> > d. The Application start the service providing it with the station\desktop
> > names as startup arguments.
> > e. The service starts ( as SYSTEM account ) and create ( using
> > CreateProcess
> > ) the management application ( the same application referred to at the
> > 'Prolog' ) setting STARTUPINFO::lpDesktop to the station\desktop pair
> > extracted from the remote desktop session by the launcher application.
> > f. The Management application starts with SYSTEM privileges ( as it was
> > created by the service ), however the GUI of the application is NOT
> > created
> > on the remote desktop session, rather, it is created on the default
> > station\desktop pair ( WinSta0\Desktop ).
> > g. Inspecting the station\desktop queried by the launcher application on
> > [d]
> > I can see that the default station\desktop ( WinSta0\Desktop ) were
> > extracted
> > and NOT the remote sessions as expected.
> >
> > Why does this happen?
> > Why can't I create a process whose GUI will be presented on the Remote
> > desktop session while it is possible to create the same process ( with
> > SYSTEM
> > privileges ) whose desktop is presented on the default station\desktop ?
> > How can I get a reference to the remote desktop session station\desktop
> > pair ?
> >
> > Any help would be appreciated.
> >
> > --
> > Nadav
> > http://www.sophin.com
> >
> > --
> > Nadav
> > http://www.sophin.com
>
>
>
From: G?nter Prossliner on 3 Nov 2006 10:21
Hi!

> 1. I am writing a DirectShow/DirectX oriented application.
> 2. This application has no real interaction with DirectShow/DirectX
> object other then enumerating available video & audio capture sources
> and presenting the capture properties.

....

> 7. Capture device enumeration DOESN'T fail when executed by a services
> started through a remote desktop session.

Why do you want to display a GUI from a service?

Why dont you just develop a service (you did it already), but instead
showing the GUI from the serivce, you just enumerate the available video &
audio capture sources and return them as a data-structure with some kind of
IPC.

Your GUI (normal windows exe started by RDC) recieves this information and
can display it or do whatever is needed (you do not need any drawing, it's
just a kind of "system information", right?). The service is not needed
anymore and can be stopped by the application.




GP


From: Nadav on 3 Nov 2006 11:38
Hi Guntar,

Indeed what you are suggesting is possible, however, I have an already
enxisting application and doing the chage you are suggesting will practically
require me to re-write that application, I wish to be sure there are no other
alternatives before doing that.
--
Nadav
http://www.sophin.com


"Günter Prossliner" wrote:

> Hi!
>
> > 1. I am writing a DirectShow/DirectX oriented application.
> > 2. This application has no real interaction with DirectShow/DirectX
> > object other then enumerating available video & audio capture sources
> > and presenting the capture properties.
>
> ....
>
> > 7. Capture device enumeration DOESN'T fail when executed by a services
> > started through a remote desktop session.
>
> Why do you want to display a GUI from a service?
>
> Why dont you just develop a service (you did it already), but instead
> showing the GUI from the serivce, you just enumerate the available video &
> audio capture sources and return them as a data-structure with some kind of
> IPC.
>
> Your GUI (normal windows exe started by RDC) recieves this information and
> can display it or do whatever is needed (you do not need any drawing, it's
> just a kind of "system information", right?). The service is not needed
> anymore and can be stopped by the application.
>
>
>
>
> GP
>
>
>
 |  Next  |  Last
Pages: 1 2 3
Prev: Getting subnet mask with GetAdaptersAddresses
Next: CreateProcessAsUser from CredProv on Vista/Longhorn Server