Ivan
Mon Dec 10 09:27:33 PST 2007
GDI does not know about Desktops.
Not event the more modern low level APIS, like DXGI,
known anything about desktops.
Let me repeat the hierarchy here for completeness:
The Video and HID-Devices are bound to a Session.
In each session, many Windowstations exists.
Only one Windowstation can be interactive.
Processes are bound to a Windowstation upon creation.
Windowstation is a container of desktops.
Each desktop is a container of a tree of windows,
windows hooks, and, the like on NtUser Objects.
A thread may be attached to a message queue,
and may be attached to a desktop.
The separation boundary offerede by a desktop
had been explained earlier. It allows and implements
the mechanism to prevent input spoofing on the Winlogon
desktop, where input-bound credentials are inserted,
and other tricks to fake input and messaging events.
Each desktop may be switched-into.
Switching to a desktop effectively attaches to that desktop
the current display information.
The display-information is the bridge between NtUser and NtGdi.
The display-info is the same for the same video/monitor configuration
regardless of the desktop. The display-info contains the PDEV/HDEV
concepts that should be familiar to anyone
who has written a display-driver.
NtGdi does not care which desktop is driving output.
In fact, NtGdi could be initialized independently, and, if you
only were use the so-called monitor-device-contextes, you would
need no whatsoever window to paint on screen.
[This causes an issue with regard of using monitor DC to paint to
the winlogon desktop using a monitor or screen DC,
that is prevented elsewhere]
As many have pointed out before you have two constrains for your problem:
If you create new desktops, then, you cannot migrate the windows
across desktops, unless you forcefully change thread desktops,
or you create selected processes in selected windowstation\desktop pairs.
This breaks the seamless-ness of the experience, and a lot of
inter-application
communications.
If you keep the same desktop (Winsta0\Default, for the sake of naming-it),
then you can create a large display information (that has, for example,
3 video/monitor devices), and you can have the windows to span/use
all of them. The problem with this approach is that
applications will always be aware (vis GetSytemMetrics, for example)
that there are either 3 monitors, and, you will have traditional problems
of off-screen windows, mouse that spans the sides of the screen, etc, etc.
--
--
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
"Terminus MGK II [Secundus]"
<TerminusMGKIISecundus@discussions.microsoft.com> wrote in message
news:AC2375F2-7F18-4A44-8348-4D89AC8A61BC@microsoft.com...
> "Alexander Grigoriev" wrote:
>> See "Multiple Display Monitors" in Platform SDK documentation.
>
> As far as I can see, the entire thing is implemented solely in GDI (hence
> the impossibility of hardware overlays (3D stuff for example) on secondary
> monitors). I can see no other way except implementing a virtual video
> driver
> for a virtual display device -- that is of course, not desirable and
> painfully slow. Can you see a better way?
>
> I have also searched the undocumented Native API for related stuff, but
> since it is GDI exclusive, I couldn't find anything usefull.
>