12,064,368 members (46,614 online)
The Remote Desktop Viewer Lite is a system to remotely monitor desktop activity. This system is designed to view a remote desktop's activity.
It is composed of three Visual C++ .NET 2003 projects
Quick Compress is a project that I have previously uploaded. I will briefly sum it up here. It is an ATL/COM component that performs Huffman compression and run length encoding. Both methods are written directly in assembler for optimized performance.
RemoteDesktopService and RemoteDesktop both call on it to compress and uncompress the data.
If it weren't for MSDN and sample code, I wouldn't have been able to have a rapid turn around on the development of the service. Please refer to the article “Creating a Simple Win32 Service in C++” by Nigel Thompson. It is located in the section DLLs, Processes, and Threads in Technical Articles. I used this program as the foundation for my service.
A Windows registration file fine tunes the behavior of the service. It controls the socket connectivity parameters, the bit depth of the display, the port to allow connections, and an optional password required to make a successful connection. If no registration file is installed, the program uses intelligent defaults, except it will use true color because it looks the best.
The socket connectivity parameters should not be adjusted unless you really know what you are doing. Here is a breakdown of their behavior:
BitCount can only be the following values; changing it to another value is undefined behavior and usually causes a failure in the GDI system.
This service runs using the following design:
Choosing this type of a project for this application did not come lightly. When I was a brand new Windows 95 programmer using C and the Win32 API solely, I would have balked at such a monstrosity. Back then I wanted to write the boiler plate code because learning Windows programming requires getting your hands dirty. Well, many years have passed since then and my zeal is about sharing the important part of my code with you.
This is a pretty simple SDI application. It derives from
CScrollView because of the wonder that class provides for scrolling around the document. So much for handling
WM_VSCROLL. Oh well, in the name of progress I suppose this is OK.
To connect to the server, use the 'New Connection'. In case of an error in connection, no real message is displayed. However if you are in debug mode you will see an error message in the debug output.
To disconnect from the server use the 'Close Connection'.
The service itself is its own installer and uninstaller.
Data flows from the client to the server and back.
We will see how data compression is integrated into the data flow.
If the server simply sent the desktop every time it changed, that wouldn't be very optimal at all. A few techniques have been added to get the size down.
This step masks out all the common bits of each desktop.
Please refer to my other article for a breakdown of the compression and encoding techniques.
The key to keeping the data is the initial second buffer, or the “last desktop”. The code uses a DIB that is filled with the color black in both the client and the server applications.
For fun you can fool around with the raster codes of these original buffers. You may get some strange kaleidoscopic effects. Just put on your favorite classic rock and trance with it.
The socket class: there is a custom, home grown socket class that handles all the communication from the client and server. Who doesn't like writing their own socket classes? It's a rite of passage as far as I am concerned. It is a robust enough class that is decently lightweight and does the trick. It has solid error detection and graceful behaviors when connectivity is lost or can't be established. It simply focuses on the Berkeley subset of socket functions available on Win32 API. I am going to leave it to the reader to break down this class.
Debug mode contains informative output for most of the system. Using the debug viewer from SysInternals is a good way to see what is going on. Another way is to run the program in the debugger and pay attention to the 'Output' tab. In the service you will have to attach to the process to get the same thing. Services can't be run like other programs but they can be debugged when you attach to them. Be prepared for Visual Studio to crash here from time to time. It sometimes has problems enumerating the processes. I've sent 20 error reports to Microsoft when I was deep in the development of this. Lucky for me that the program creates its own report and asked me if I wanted to send it on. I enjoyed spamming Microsoft with these reports.
The zip contains all the source code and projects.
If you redistribute the application make sure to put the QuickCompress.dll in the application path.
The following chart shows some typical compression ratios using a 1280 x 960 resolution display. In debug mode the actual amount of data that is sent for each desktop is sent to the debugger output.
(You wondered why I called it the lite version.)
Each socket represents a grid of the screen and is responsible for sending only its data. This concept helps leverage the power of your networking to handle more than one data stream at a time.
I've contemplated on a screen divided into 4 areas ought to deliver the best performance and compression.
Ahh.. the real deal here. This is where I am ultimately headed. I have the Windows DDK which describes how to build a graphics mirror driver.
Balancing this type of graphical refresh with my method ought to really deliver a punch and make this program a real contender to VNC.