Virtual Monitor in VB.Net?

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

Jim Hubbard

Is it possible to emulate a monitor (create a virtual monitor) using vb.net?

Any code snippets or pointers to helpful articles would be very much
appreciated.
 
you mean like a VNC connection? yes, if you really know extensive windows
API calls you can do this. But will you find any example code for it? might
be very hard to, you might have to convert c++ code to VB.NET
 
No. Not like VNC.

VNC is relatively slow and not capable of the screen recording that I want
to do. Conversion of VNC from C++ to VB.Net would not really help the speed
or compression of the images at all.

I suspect what I am in need of would be more like a virtual device driver
and would require unmanaged code that VB.Net is not capable of.
 
Hi, may I ask what exactly you mean by a "virtual monitor"? Do you mean
another desktop (e.g. using the CreateDesktop API's) or do you mean a
terminal services connection?

--
HTH,
-- Tom Spink, Über Geek

Woe be the day VBC.EXE says, "OrElse what?"

Please respond to the newsgroup,
so all can benefit
 
I want to capture the GDI stream from GDI to the desktop device context.
I'd like to intercept and copy this stream in order to play back the desktop
at a later time.

I know that (starting with WIN98) Microsoft included the capability to
support multiple monitors. They speak VERY briefly about something called
the "Display Device Management Layer" (or DDML) that they say is explained
in more detail in the DDK.

I have yet to find any useable information in the 2003 DDK concerning the
"Display Device Management Layer" or it's use.

I figure that the DDML is the proper way to do this, but since I cannot find
any info on it - I need some way to intercept the GDI calls and save them to
a file.

By saving the GDI calls, I hope to allow playback on any display device
running under Windows 98 and up without worrying about configurations or
capabilities of the display devices - as display devices will take the GDI
calls and interpret them to playback in correctly for the given device
context.

A video hook may be what I'm after......whatever let's me get a stream of
all GDI calls sent to the desktop. I figure that a virtual monitor would
get the GDI calls sent to the physical monitor and would be one way to get
the GDI calls I want to save.

This is not a terminal services connection.
 
Hi, will the end result be an animation of the desktop... or will it be
actually recreating the actions?

--
HTH,
-- Tom Spink, Über Geek

Woe be the day VBC.EXE says, "OrElse what?"

Please respond to the newsgroup,
so all can benefit
 
Animation.

Actual recreation would require a lot more coding. You'd have to record
mouse movements and clicks, keyboard activity and check to make sure that
the items clicked on still existed and were in the same place. Then you
would run into the problem of overwriting files or possibly trying to access
files that did not exist. A real nightmare.

I'll stick with just showing what happened for now.
 
Found the following in the 2003 DDK.....

----------------------------------------------------------------------

Mirror
[This is preliminary documentation and subject to change.]

SUMMARY
This sample demonstrates how to use a driver to perform video mirroring.
When video mirroring is active, each time the system draws to the primary
video device at a location inside the mirrored area, a copy of the draw
operation is executed on the mirrored video device in real time. With this
mirroring scheme, you can simultaneously draw the same output to several
video devices. Since the driver allocates memory dynamically for targets,
the number of displays that your system can support depends on how much free
memory you have at mirror-time.

This sample is designed to provide information on a standard, generic method
of mirroring. This eliminates the need for special case-by-case solutions
which were used before this support was added to the system. The sample runs
only on the Microsoft® Windows® 2000 platform. It features commented source
code that documents in detail how the code works, to make it easy to modify
and extend. Please note that this is the first version of the video mirror
sample. Additional functionality may be added to the sample in future
releases.

The sample is comprised of three pieces:


a.. The display driver, in \Ntddk\Src\Video\Displays\Mirror\Dll.
b.. The video miniport driver, in \Ntddk\Src\Video\Miniport\Mirror. The
miniport driver included here is a skeleton. It simply returns success
status for all miniport calls made by the system as there is no real
hardware controlled by the mirror sample.
c.. An application that is a sample user-mode service, in
\Ntddk\Src\Video\Displays\Mirror\App.
For additional information about this sample and about mirror drivers in
general, please see \Ntddk\Src\Video\Displays\Mirror\App\Readme.txt, and the
Mirror Drivers topic in the Graphics Design Guide.

BUILDING THE SAMPLE
Install the driver by using the included .ini file, then run the sample
application. The application will attach the driver to the desktop, and
mirroring will be active. At present, the sample application is a
command-line Win32 program.

Notes: The sample is x86 compatible. It also compiles correctly in the
64-bit environment. All aspects of the kernel-mode execution environment
apply to the display and video miniport driver portions of this sample.

----------------------------------------------------------------------

It is c/c++....languages I do not speak. And, it seems that writing a
generic driver using this method is slightly over my head.

I can't seem to shake the thought that there should be something in the GDI
APIs that would allow you to hook the GDI stream without all of this.
However, this method may be the most efficient - and efficiency is exactl
what I need.
 
I am doing screen capture for a longtime, Video Mini-port is the most efficent way as I know. For Monitor recording, you can use
Windows Media Encoder 9, But it's performance is simular to GDI BitBlt.

There are 3 ways to capture screen as I know, GDI BitBlt, DirectX, and Media Encoder.
GDI Bitblt is the easiest way to capture screen, But if you want to encode the screen to a video, you can use MediaEncoder method.
DirectX Capture screen is not as fast as I imaging, it's performance similar to GDI bitblt, but it will not lag your screen like GDI
bitblt.

Anyway, I think you should use video mini-port driver, it's really fast. You can try SuperVNC, which support Mini-port driver.

--
Samson Fu
Jim Hubbard said:
Found the following in the 2003 DDK.....

----------------------------------------------------------------------

Mirror
[This is preliminary documentation and subject to change.]

SUMMARY
This sample demonstrates how to use a driver to perform video mirroring.
When video mirroring is active, each time the system draws to the primary
video device at a location inside the mirrored area, a copy of the draw
operation is executed on the mirrored video device in real time. With this
mirroring scheme, you can simultaneously draw the same output to several
video devices. Since the driver allocates memory dynamically for targets,
the number of displays that your system can support depends on how much free
memory you have at mirror-time.

This sample is designed to provide information on a standard, generic method
of mirroring. This eliminates the need for special case-by-case solutions
which were used before this support was added to the system. The sample runs
only on the Microsoft?Windows?2000 platform. It features commented source
code that documents in detail how the code works, to make it easy to modify
and extend. Please note that this is the first version of the video mirror
sample. Additional functionality may be added to the sample in future
releases.

The sample is comprised of three pieces:


a.. The display driver, in \Ntddk\Src\Video\Displays\Mirror\Dll.
b.. The video miniport driver, in \Ntddk\Src\Video\Miniport\Mirror. The
miniport driver included here is a skeleton. It simply returns success
status for all miniport calls made by the system as there is no real
hardware controlled by the mirror sample.
c.. An application that is a sample user-mode service, in
\Ntddk\Src\Video\Displays\Mirror\App.
For additional information about this sample and about mirror drivers in
general, please see \Ntddk\Src\Video\Displays\Mirror\App\Readme.txt, and the
Mirror Drivers topic in the Graphics Design Guide.

BUILDING THE SAMPLE
Install the driver by using the included .ini file, then run the sample
application. The application will attach the driver to the desktop, and
mirroring will be active. At present, the sample application is a
command-line Win32 program.

Notes: The sample is x86 compatible. It also compiles correctly in the
64-bit environment. All aspects of the kernel-mode execution environment
apply to the display and video miniport driver portions of this sample.

----------------------------------------------------------------------

It is c/c++....languages I do not speak. And, it seems that writing a
generic driver using this method is slightly over my head.

I can't seem to shake the thought that there should be something in the GDI
APIs that would allow you to hook the GDI stream without all of this.
However, this method may be the most efficient - and efficiency is exactl
what I need.
 
I am finding it very difficult to find anyone that is willing to undertake
this challenge, though I have offered to pay for it.

I could not find SuperVNC. Perhaps you mean UltraVNC.....which I have been
a fan of for quite some time.

If I could get what I want done, I may even want to put out a free remote
desktop package - like VNC, but faster.

Samson Fu said:
I am doing screen capture for a longtime, Video Mini-port is the most
efficent way as I know. For Monitor recording, you can use
Windows Media Encoder 9, But it's performance is simular to GDI BitBlt.

There are 3 ways to capture screen as I know, GDI BitBlt, DirectX, and Media Encoder.
GDI Bitblt is the easiest way to capture screen, But if you want to encode
the screen to a video, you can use MediaEncoder method.
DirectX Capture screen is not as fast as I imaging, it's performance
similar to GDI bitblt, but it will not lag your screen like GDI
bitblt.

Anyway, I think you should use video mini-port driver, it's really fast.
You can try SuperVNC, which support Mini-port driver.
--
Samson Fu
Found the following in the 2003 DDK.....

----------------------------------------------------------------------

Mirror
[This is preliminary documentation and subject to change.]

SUMMARY
This sample demonstrates how to use a driver to perform video mirroring.
When video mirroring is active, each time the system draws to the primary
video device at a location inside the mirrored area, a copy of the draw
operation is executed on the mirrored video device in real time. With this
mirroring scheme, you can simultaneously draw the same output to several
video devices. Since the driver allocates memory dynamically for targets,
the number of displays that your system can support depends on how much free
memory you have at mirror-time.

This sample is designed to provide information on a standard, generic method
of mirroring. This eliminates the need for special case-by-case solutions
which were used before this support was added to the system. The sample runs
only on the Microsoft?Windows?2000 platform. It features commented source
code that documents in detail how the code works, to make it easy to modify
and extend. Please note that this is the first version of the video mirror
sample. Additional functionality may be added to the sample in future
releases.

The sample is comprised of three pieces:


a.. The display driver, in \Ntddk\Src\Video\Displays\Mirror\Dll.
b.. The video miniport driver, in \Ntddk\Src\Video\Miniport\Mirror. The
miniport driver included here is a skeleton. It simply returns success
status for all miniport calls made by the system as there is no real
hardware controlled by the mirror sample.
c.. An application that is a sample user-mode service, in
\Ntddk\Src\Video\Displays\Mirror\App.
For additional information about this sample and about mirror drivers in
general, please see \Ntddk\Src\Video\Displays\Mirror\App\Readme.txt, and the
Mirror Drivers topic in the Graphics Design Guide.

BUILDING THE SAMPLE
Install the driver by using the included .ini file, then run the sample
application. The application will attach the driver to the desktop, and
mirroring will be active. At present, the sample application is a
command-line Win32 program.

Notes: The sample is x86 compatible. It also compiles correctly in the
64-bit environment. All aspects of the kernel-mode execution environment
apply to the display and video miniport driver portions of this sample.

----------------------------------------------------------------------

It is c/c++....languages I do not speak. And, it seems that writing a
generic driver using this method is slightly over my head.

I can't seem to shake the thought that there should be something in the GDI
APIs that would allow you to hook the GDI stream without all of this.
However, this method may be the most efficient - and efficiency is exactl
what I need.
 
I'm not sure how much faster you can get, the speed depends on the
connection pretty much. although the optimized version of that is RDC built
into XP and terminal servers, which is about as optimized as you will get,
but very hard to code something like that, and would not get much faster
unless you coded it in C++, you would have some performance drops because of
the CLR compared to running in native W32.
 
The speed that I am after is not the connection speed, but rather the screen
capture speed and transfer speed (smaller packets for the same amount of
data).

RDC uses the DDML which uses device mirroring to emulate a second monitor
and send the GDI instructions that go to the main monitor to the second
device.

C++ is definitely the way to go for the mirror DLLs and any activeX controls
that may be constructed to make the use of such mirror devices easier to
play with.

Unfortunately, I cannot find anyone with the skills, will and time to take
on this little project. I have tried to hire coders on Rent-A-Coder and
Guru.com to no avail.

Perhaps you know of someone that is interested in this project that has the
skills, will and time to take it on?
 
Yes. it's ultraVNC, sorry for my mistake...
And you can take a try to netop remote control. which is more faster than ultraVNC, I don't know how it can be, but it dose..

--
Samson Fu
Jim Hubbard said:
I am finding it very difficult to find anyone that is willing to undertake
this challenge, though I have offered to pay for it.

I could not find SuperVNC. Perhaps you mean UltraVNC.....which I have been
a fan of for quite some time.

If I could get what I want done, I may even want to put out a free remote
desktop package - like VNC, but faster.

Samson Fu said:
I am doing screen capture for a longtime, Video Mini-port is the most
efficent way as I know. For Monitor recording, you can use
Windows Media Encoder 9, But it's performance is simular to GDI BitBlt.

There are 3 ways to capture screen as I know, GDI BitBlt, DirectX, and Media Encoder.
GDI Bitblt is the easiest way to capture screen, But if you want to encode
the screen to a video, you can use MediaEncoder method.
DirectX Capture screen is not as fast as I imaging, it's performance
similar to GDI bitblt, but it will not lag your screen like GDI
bitblt.

Anyway, I think you should use video mini-port driver, it's really fast.
You can try SuperVNC, which support Mini-port driver.
--
Samson Fu
Found the following in the 2003 DDK.....

----------------------------------------------------------------------

Mirror
[This is preliminary documentation and subject to change.]

SUMMARY
This sample demonstrates how to use a driver to perform video mirroring.
When video mirroring is active, each time the system draws to the primary
video device at a location inside the mirrored area, a copy of the draw
operation is executed on the mirrored video device in real time. With this
mirroring scheme, you can simultaneously draw the same output to several
video devices. Since the driver allocates memory dynamically for targets,
the number of displays that your system can support depends on how much free
memory you have at mirror-time.

This sample is designed to provide information on a standard, generic method
of mirroring. This eliminates the need for special case-by-case solutions
which were used before this support was added to the system. The sample runs
only on the Microsoft?Windows?2000 platform. It features commented source
code that documents in detail how the code works, to make it easy to modify
and extend. Please note that this is the first version of the video mirror
sample. Additional functionality may be added to the sample in future
releases.

The sample is comprised of three pieces:


a.. The display driver, in \Ntddk\Src\Video\Displays\Mirror\Dll.
b.. The video miniport driver, in \Ntddk\Src\Video\Miniport\Mirror. The
miniport driver included here is a skeleton. It simply returns success
status for all miniport calls made by the system as there is no real
hardware controlled by the mirror sample.
c.. An application that is a sample user-mode service, in
\Ntddk\Src\Video\Displays\Mirror\App.
For additional information about this sample and about mirror drivers in
general, please see \Ntddk\Src\Video\Displays\Mirror\App\Readme.txt, and the
Mirror Drivers topic in the Graphics Design Guide.

BUILDING THE SAMPLE
Install the driver by using the included .ini file, then run the sample
application. The application will attach the driver to the desktop, and
mirroring will be active. At present, the sample application is a
command-line Win32 program.

Notes: The sample is x86 compatible. It also compiles correctly in the
64-bit environment. All aspects of the kernel-mode execution environment
apply to the display and video miniport driver portions of this sample.

----------------------------------------------------------------------

It is c/c++....languages I do not speak. And, it seems that writing a
generic driver using this method is slightly over my head.

I can't seem to shake the thought that there should be something in the GDI
APIs that would allow you to hook the GDI stream without all of this.
However, this method may be the most efficient - and efficiency is exactl
what I need.
 
Samson Fu said:
Yes. it's ultraVNC, sorry for my mistake...
And you can take a try to netop remote control. which is more faster than
ultraVNC, I don't know how it can be, but it dose..

Well, here's how.....they are hooking the GDI (what I wanted to do). The
following is taken from their website at
http://www.crossteccorp.com/news_july_2003.html#tech_tip .

----------------------------------------------------------------------------
--------
TECH TIP: GDI HOOKING & BITMAP AND HOW THEY EFFECT SPEED

One of the prime considerations in considering remote control software is
speed in the screen draws. Screens can be transmitted in one of two common
ways: GDI hooking and Bitmap. GDI hooking involves intercepting the draw
commands and sending a copy of these commands to the remote PC for
reproduction. This method is used by default in NetOp, it is very fast, and
makes for very small amounts of data moving across the wire. Bitmap mode is
slower and involves sending more data, since this method merely looks into
the video buffer and sends a bitmap representation of the screen down the
wire to the remote PC. NetOp will first try a GDI hook. If this fails it
will resort to bitmap mode.

NetOp version 7.6 is up to 40% faster than previous versions of NetOp. Part
of this speed improvement is the result of tighter TCP/IP coding in the
transport mechanism and part is due to a new bitmap algorithm. Why should
you care about a new bitmap algorithm? Even in a GDI hook there are still
bitmaps that need to be painted (think application splash screens, among
other things). Additionally GDI hooking is only valid Windows to Windows, so
if you need to mix in OS/2, Mac OS X, Linux, Unix, or Solaris, you are now
100% bitmap, where our newly improved intelligent algorithm will give you
some very good performance.

For more information please visit:
http://www.crossteccorp.com/techtips/index.html
----------------------------------------------------------------------------
--------

Although hooking like this is good, using the DDML to mirror the desktop is
a better solution and is the solution recommended by Microsoft.

Looks like I'll need to learn C/C++ and do this myself.
 
I have tried to hook gdi APIs before. I can hook almost application's API. But some system GDI API is not hookable, at least for me.
And I give up to use API hooking now, I found hooking is not what I need, coz I want to transfer one computer to multiple computers
using broadcast.. and If one packet failed, all the following instructions will become rubbish...
Just imaging 2 instructions, the first draw a circle, the second floodfill inside the circle... If first instruction failed, what
will happen for second instruction?
 
I see what you mean. Luckily DDML takes care of that by mirroring the
desktop to another device. It is suggested that remote control applications
use this by Microsoft.

I'd hire someone to code it for me, but I can't find anyone that is capable
of writing it. I'd write it myself, but I have to learn C/C++ first.

Samson Fu said:
I have tried to hook gdi APIs before. I can hook almost application's API.
But some system GDI API is not hookable, at least for me.
And I give up to use API hooking now, I found hooking is not what I need,
coz I want to transfer one computer to multiple computers
using broadcast.. and If one packet failed, all the following instructions will become rubbish...
Just imaging 2 instructions, the first draw a circle, the second floodfill
inside the circle... If first instruction failed, what
 
Back
Top