Re: C++ exception before WinMain

"Remi de Gravelaine" <gravelaine at aton dash sys dot fr> wrote in
news:udy$#nMZHHA.984@xxxxxxxxxxxxxxxxxxxx:

[...]
It is something i'll have to do too. If it is possible to know
what he did to solve the "efficient update" problem, I am strongly
interested!

It's more or less what you said in your post.
Catching display update operations an require a VNC update only when
needed. It's the same architecture that some VNC implementations on
Win32 do using a "dummy" driver.
A more portable implementation involves a driver that "wraps" the
original one and intercepts updates only when VNC is running.
I think that you can do that but you'll have to "install" your driver
in place of the original one and this may need some forms of persistent
registry (unless you can add the keys inside PB, of course) or using
the shim engine (a part of CE that I would like to understand
better...).
I think that my customers already sell a device with the client
capabilities built-in.
If you are interested, e-mail me and I'll give you their contacts (I
did some training and support to them but I'm not involved in that
project).

[...]
(http://libvncserver.sourceforge.net/).
Thanks for the info. I had a Google check on "libVNC" but I am not
sure this is interesting for me, compared to TightVNC:
"Libvnc, a VNC module for xrdp. Libvnc provides a connection to
VNC servers. Its a simple client only supporting a few VNC
encodings(raw, cursor, copyrect). Emphasis on being small and
fast. Normally, the xrdp server and the Xvnc server are the same
machine so bitmap compression encodings would only slow down the
session."

On the site it seems that the client part now supports also some kind
of compression. But their webpage is not very detailed...
Since you said that the server has a powerful CPU, compression can be
useful to increase performances and reduce bandwidth even on a fast
network. But you should choose a compression algorithm that the client
can handle fast enough (even if usually decompression is faster than
compression...).

To give the big picture, I have to implement a remote terminal
under CE: a (rather powerful) headless machine is connected
through TCP/IP on a (less powerfull) device having a screen, mouse
and keyboard. The screen displays what the first machine puts in
its frame buffer and the mouse moves and keystrokes detected by
the second device are redirected to the first machine. Both
machines run under CE. Lacking a Windows CE Terminal Server (tell
me if such a thing exists!), I started this TightVNC port to CE.

I checked some remote-control software on CE for one of our customers
(NetOP?) but they don't provide much information about teir SW and a
non-PPC/Windows mobile version...

Of course, the key for efficiency is to avoid the server scanning
of the frame buffer when nothing have changed on the display. I
had in mind to implement a "dirty rect" display driver on the
server machine to trigger the VNC server but I am wondering if
this kind of driver is still supported in CE 4.2+.

I think that you don't need a dirty rect driver, only a way to keep a
"invalid" rects queue from driver to the VNC server. The server can
read the queue and merge the rects it reads (if they intersect, at
least) to reduce the number of updates needed.
You should intercept few driver calls to know that a part of the
display has been update and you can get the BMP using GetDC.

If you have two CE devices you may try to "redirect" driver calls and
use the FLAT display driver to re-do the operation on the viewer
framebuffer. This solution will be less portable (at least for the
server-side) but may be faster since you won't need to encode bitmaps
for high-level operations (line drawing, fills etc.).

Again, all relevant information is welcome.

HTH

--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)
.

Relevant Pages