Intercepting GDI calls

[Charles Davis]

Jui-Hao Chiang wrote:
> Hi, all:
> 
> I am currently starting a project which tries to run a window
> application on one (source) machine, and display on another
> (destination) machine. Of course, the VNC or X11 forwarding technique
> can achieve the same goal, but I am trying to reduce the bandwidth by
> "not" transferring the video frame buffer but transfer the GDI
> function calls instead.
Uhhh... That's kinda how X11 works. I mean, sending drawing and
windowing calls as opposed to transferring the entire FB.

What do you hope to accomplish with this? Given what I just told you,
why won't X11 suffice?
> 
> The way I can see is try to intercept all the calls inside gdi32.dll,
> and forward the calls and parameters to remote machine by using some
> RPC library, and then replay the GDI calls on the destination machine.
> 
> However, I have two doubts:
> (1) It seems like the user32.dll is actually handling the window,
> menu, and cursor.
That's right.
 Does the drawing of menu and cursor depends on
> user-level gdi32.dll? 
Yes it does. But bear in mind that gdi32 doesn't know how to draw menus
and cursors, and other things. It only draws what you tell it to draw.
You have to specify what you want to draw in terms of primitive shapes.
That's what user32 does.
or other kernel-level dlls?
What kernel-level DLLs? Wine is entirely user mode. Don't let the
presence of "ntoskrnl.exe" fool you; that's done in user mode, too :).
> (2) It seems that there is no corresponding win32k.sys implementation
> in wine, and the user-level GDI calls seems to be forwarded to
> winex11.drv, right?
That's correct. (In the future, that might change, especially on a
certain OS made by a company named after fruit. But rest assured,
there's not going to be a win32k.sys implementation anytime soon.)
> 
> I wander is there any good way or a place inside the source to do this
> kind of interception?
If you really want to go through with this, what you want to do is write
your own driver, similar to winex11.drv. In fact, I suggest using it as
a base. Then you can forward the calls to some other machine (running
Windows or some other OS) with RPC or some such mechanism.

Chip