GDI questions...

  • Thread starter Thread starter Jim Hubbard
  • Start date Start date
J

Jim Hubbard

Can you use VB.Net to set a system-wide hook to intercept all GDI calls from
GDI to the system's hardware? I want to intercept all GDI instructions sent
to the system's hardware layer.

As I understand it (and I may be missing something) GDI sends instructions
to a DEVICE (which can be a printer or display unit or any device for which
a device context can be obtained) and the device does the drawing.

Also...if anyone can tell me how the dual (actually up to 9) monitor display
thing works - starting with Win98 - that'd be fantastic. If I knew how that
works, I think it'd help me in my screen captures.
 
Sure....I could. But, that'd also require multiple BitBlt() calls, then I'd
have to save the images in a compressed format over and over.

As fast as BitBlt is, writing the images to the hdd is not nearly as fast.
Although I could keep the images in an array and only write every so often,
the array would fill up far faster than the ability to compress them and
write them to disk.

By trapping the GDI stream (basically text) I can compress and hold MUCH
more information than with actual images with no loss of color or size in
the images.

Thanks for the post though!
 
just an idea (not tested, not even sure it would work)
what about an in-memory picture woth CreateCompatibleDC()
the call BeginPaint() with this HDC and a HWND of ((HWND) 0) ?
and then save the picture ?

you don't get all the internal info but it's simple! it might even work ?!
 
Hi Jim,

I do not think intercepting GDI calls is the right sollution, especially because dll hooking/interception is mainly provided for debugers, and is by some programs considdered hostile.

A better way would be to build a mirror display driver. You can find samples and documentation for this in the Windows DDK:
http://msdn.microsoft.com/library/e..._b57d0d90-5dae-447d-825f-7d4a05e1e6d0.xml.asp

Also, I do not think VB.NET is the right tool to use, althoug it might be possible, it would require extensive headerfile conversions and nasty hacks.

Best regards,
Christoph Lindemann
 
Mirror display drivers are doing exactly that - capturing (or, more
precisely, duplicating) the GDI calls to the main screen.

You are right to point out that VB.Net is not appropriate for the job. But,
the samples you have pointed to do me no real good - as I am C/C++
illiterate.

I have (for better or worse) dedicated myself to being the best VB/VB.Net
programmer I can be. At this point, I can say I wish I had spent some time
learning C++.

Acknowledging the fact that it would take me a year or more to gain the
skills and knowledge to write such a mirror device, it is more prudent to
hire someone to write what I need.

Alas, I cannot find anyone with the skills to do this that also has the time
to take on another project.

My search continues for a competent, proven programmer or company with the
skills, time and will to take on this job.

Know anyone? ( I have tried Guru.com and Rent-A-Coder with no success.)



Christoph Lindemann said:
Hi Jim,

I do not think intercepting GDI calls is the right sollution, especially
Click to expand...
because dll hooking/interception is mainly provided for debugers, and is by
some programs considdered hostile.
A better way would be to build a mirror display driver. You can find
Click to expand...
samples and documentation for this in the Windows DDK:
http://msdn.microsoft.com/library/e..._b57d0d90-5dae-447d-825f-7d4a05e1e6d0.xml.asp

Also, I do not think VB.NET is the right tool to use, althoug it might be
Click to expand...
possible, it would require extensive headerfile conversions and nasty hacks.
 
woaw, amazing.

BTW Jim, I didn't see the source yet, but it's a relativaly new article.
I'll bet you will be able to download a compilable sample in a couple of
days.. (weeks ?) or you could contact microsoft about where are the sources
for this article ?
I had found them very responsive !
and then, with the source, the problem would be almost solved, wouldn't it ?

And if you want to learn C/C++, at work, starting by C, it takes no more
than a couple of weeks (2~3), don't be so impress, C is easy! and C++ is not
that much harder than C!
 
I will look into studying C/C++....especially if I can grasp it in only a
month.

If you'd like this source code, I can email it to you - send your request to
(e-mail address removed) (ignore all UPPERCASE letters in the email
address and that's 2 underscores between jim and hubbard.)

Thanks for your post.

And props to Christoph for the link! I have the 2003 SDK, but hadn't seen
this link before.

The one thing that concerns me is that the article says "Note In Windows
2000 and later, the mirror driver's clip region must include the primary
display device." I take this to mean that the clip region for 2000 and up
must include the whole desktop.

I think that this means that I would not be able to limit the mirroring to
just one window, unless that window covered the whole screen.
Disappointing.

I'll go get a couple of books today, and let you know how I make out in
about a month.

Thanks again!
 
no thanks, I'm not much into driver developement myself :)
I just found this interesting, as a... demo.
but good luck!
 
TightVNC has a driver that was donated to be used with TightVNC from
DemoForge. The TightVNC developers are working on an open source version of
their own, but also need some help.

I'm not a real big believer in Open Source. And, I'd want my components to
be proprietary - not possible if the TightVNC guys do it as it would come
under the GPL.

DemoForge has given me permission to use their drivers in a new open source
project. I'll post something here as soon as it is ready.

Thanks for the post.
 
Back
Top