Actually, you’ve got it just about right except for the packaging part. In
Terminal Services, there is a display driver called rdpdd.sys that is a
display driver itself. It actually does the capturing, packaging and
routing to rdp which then does the transmission to the remote machine. I
don’t want to have to deal with the packaging and such, so what I’d like to
do is sit in the display driver chain before rdpdd.sys. This way I can muck
w/ the GDI calls before rdpdd. After I have my fun, rdpdd will get the call
(at this point, all should be transparent to rdpdd) and away the call goes
as normal.
I thank you for the suggestions. I have been reading the DDK docs and
looking at the source code. I suppose this being my first time ever looking
into writing a device driver makes this information seem overwhelming. I
had a feeling that reading the DDK docs to learn to write a device driver
was like reading MSDN to learn how to program C++ and Windows (that didn’t
work for me anyhow). I was hoping that there was a way that was little more
clear cut, but perhaps. It can’t always be easy :>
I thank you very much for the response and suggestions.
Bill
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Thursday, June 14, 2001 13:47
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions
I don’t know much about TS, but intercepting all display driver calls may be
a tall order! The first thing to do is to read the “Graphics Drivers”
section of the DDK documentation, and take a look at some of the samples at
your \ddk\src\video directory. Display drivers are plain vanilla DLLs, they
do not follow WDM or WinNT device driver models; there are no IRPs, no
driver stacks, no interrupts to handle, no DPCs, and so on. There’s just the
calls, the data structures, and the iron.
And be prepared for the eventuality of having to write a whole lot of code!
I am assuming, from what I understand, that what he wants to do is to
intercept DDI calls, munge them, package them into some sort of packet, and
ship them out to the remote machine. This can be done, but it’s a big job,
because there are so many entry points to negotiate: DrvXxxxx, EngXxxxx,
DdXxxxx, D3dXxxxx, OpenGL MCD and ICD, Wgl, and more. Then you’re going to
have to allow for punting to the native display driver. Then you’re going to
have to handle bitmap caching. Then you’re going to have to make sure that
when your display driver punts to the GDI, that the GDI has a consistent
view of your remotes. Then you have the issue of handling multiple monitors.
Then you have Dos Box issues. Then you have to negotiate dynamic mode
changes. Then you’ll bump into people who drive their hardware directly from
Ring 3, without going through the display driver. Then you may have to
support negotiation and synchronization between the 2D and 3D drivers, and
that negotiation is often private to the graphics chip vendor and not
documented, and it changes from chip to chip and from machine to machine.
And much more. I don’t know, are you sure you want to go that way ? Sounds
to me like a lot of work! You may be opening a Pandora’s box by starting
this kind of project.
But hey, if you find a decent way of going about it, more power to you! Hope
this helps,
Alberto.
-----Original Message-----
From: Barila, Phil [mailto:xxxxx@intel.com]
Sent: Thursday, June 14, 2001 12:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions
There don’t seem to be many display driver writers on this list, so I’m not
sure how much help we’ll be to you, but I hope someone else knows how to
solve the problem you are trying to solve.
I’ll admit right now that I don’t still understand the problem. You
mentioned Terminal Services, and I am just not getting what you are trying
to use it for. Is your app executing locally to the hand-held, or remotely
on the TS? TS enables you to execute a GUI app on a remote CPU. It won’t
help you much if you are just trying to get the remote CPU to exec a process
for you. There are *much* better ways to get REXEC functionality than TS.
If it’s on the TS, is it possible to just rewrite the GUI of your app to do
what you want? Again, I don’t really understand the problem, but if you
explain it well enough for *me* to understand, you might stir *someone* to
think up the right solution.
Phil
-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Thursday, June 14, 2001 4:46 AM
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions
There is a terminal services client for our hand held OS, however, we want
to scale specific applications very specific ways (and perhaps include and
exclude certain parts of different screens). We actually have an old DOS
based product (character based) that works this way where you can include
and exclude certain fields. We’re trying to emulate that behavior as much
as possible in a GUI environment.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Barila, Phil
Sent: Wednesday, June 13, 2001 16:58
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions
I can’t tell if you are trying to write a Terminal Services client for your
hand-held OS or something else. But it sounds like the problem you are
trying to solve would be solved if there was a Terminal Services client for
your hand-held OS. Is this correct?
-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Wednesday, June 13, 2001 1:40 PM
To: NT Developers Interest List
Subject: [ntdev] display driver questions
Hello,
First off, apologies as I am extremely new to the device driver world (been
an application guy for 6+ years). Our R&D team is researching a way to
accomplish a seemingly small task. That task being, a way to allow our
users to scale our Win32 applications to fit onto hand held devices. We’d
like to do this using Terminal Server to run and display the data on the
hand helds.
It sounds like what I need to do is write a “dummy” display driver and
insert it into the display driver chain so that I can intercept all GDI
calls and reformat them according to very specific instructions from our
users. After that, I can pass it along to the “real” display driver. I
can’t use DDML because nothing is going to the display per se (it’s going to
rdpdd.sys through terminal server).
Does this sound feasible? If so, can someone give me some clues as to how I
might get started writing this dummy display driver? I have the DDK and the
book by Newcomer but I’m getting nowhere fast. Any help is greatly
appreciated. Thank you.
Bill Buchanan
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@connectrf.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com