Hi all !
My goal is to send a portion of physical display data over a network, as
an image (ala remote desktop software). Instead of doing a remote graphic
procedure call system, i will simply send the whole area as an image.
My problem is that the data sent will be available at all times, across
user desktops, this including locked workstation screens, screensavers and
everything that is displayed on the screen as long as Windows runs.
I am getting an impression that to get under the desktop / GDI system I
need to write a driver …possibly a mirror driver.
I have peeked into DDK, mirror driver samples, and OSROnline’s The
Basics…I have experience writing user mode software, GDI especially.
What I lack is understanding of the whole display driver vs mirror driver
vs miniport driver…Mirror driver samples in DDK folder are split into
three catalogs, which makes things even more cryptic to me 
Will i only have to write a single mirror driver for my needs that will
store the image in some user buffer that another user mode program will
access, and if so, where can I get a head start on that ?
Thanks in advance ! 
(1) To learn get a debugger - say windbg.
(2) Build the sample mirror driver and install it - setting breaks and
looking at code execution and reading the DDK online help.
(3) Start with a break or DbgBreakPoint() in the function DriverEntry in
the Mirror Driver.
(4) You should build a miniport driver to access the Framebuffer. Again
set break points in it.
(5) Note that the regular display driver get calls first and then the
mirror driver. I believe that is correct. While in the Windows 95
technology using the Accessiblity SDK it is the other way arount. Plus in
95 it is a ring 3 DLL in x86 Intel Land while in NT Technology in x86
space it is a ring 0 sys file.
Do you mean i should write BOTH mirror AND miniport driver, latter to
access display memory ?
Thanks for the rest, i have Windows DDK, along with WinDBG and all the
other utils!
(1) I did this for a colleague. I used the Mirror sample for the NT
Technology. Note you can call the miniport from your driver to get the
virtual address of the Frame Buffer. Note DirectDraw does it this way.
Yes I would write both a display driver and miniport driver. I would call
the miniport from the display driver from a DeviceIoControl that an
application could issue. In the miniport you have to do
VideoPortMapMemory() and pass by the Virtual Address of the Framebuffer
and you will have page table entries as well from VideoPortMapMemory().
Next go ahead and write to the Virtual Address say all 0xFF which will be
a white line. You should see this on the screen.
As Alberto mentioned, this can be done in user mode. Depending on your
implementation though, you can get better performance out of doing this in
kernel mode via a mirror driver.
You need to read up on the display driver architecture in windows. The
mirror driver is basically a ‘real’ display driver, just the miniport
portion is a ‘skeleton’ driver that doesn’t really need to talk to
hardware, etc.
Also, you are *not* guaranteed that the real display driver is called
prior to the mirror driver. At the moment in current OSes, this seems to
be the case, but Microsoft does not guarantee that it will work that way
(or so they’ve told me). And there is no reason why this should matter.
GDI duplicates or breaks a call up into different drawing calls to make
sure that the mirror driver gets everything it needs to draw onto its
‘surface’. Whether this happens before or after the main display driver
draws should not matter to the mirror driver.
So, just pick up the DDK docs and start reading about the display driver
architecture, and the mirror driver stuff will make much more sense to you
after that…
Hope this helps,
sean