What is the plan to move forward with a WinVNC for the Windows platform?  I know I would really like a uniform version that I can use across all the platforms I work with.  I am currently switching to TigerVNC for all Linux and Mac based clients but am having to use old TightVNC 1.3.x for Windows XP and TightVNC for Vista/7.  I know what kind of work the TightVNC team did in making the 2.0.x release run well on newer Windows versions.  It was basically a full rewrite from scratch though that had more to do with their desire to have a clean code base they could relicense commercially. 

For making WinVNC compliant with the new security measures, the WinVNC program has to be split in two.  One half is the service that is setup with network IPC and the other half is the nice pretty gui that does IPC with the service process. 

The current TigerVNC implementation has the best encoder/decoder but must be split into the two pieces in order to work correctly.

The current 2.0.x TightVNC is a completely new API.  It is laid out well but does not have the encoder performance and would be a separate encoder/decoder. 

It might be possible to borrow the client portion of TightVNC 2.x to have a quick way to build the client half of the WinVNC process but it would still take a bit work work to get the backend service WinVNC part playing nice. 

I know I am basically just a random beta tester but this is something I have been looking into for a while.  I am curious which way the project wants to go to move forward with a better WinVNC for Tiger.  I can deal with the loss of MSVC support though I don't like having to do the (dirty) workarounds that using mingw requires for some things.  What is the plan moving forward code wise for Windows/WinVNC?

Robert


On 11/07/2011 04:21 PM, DRC wrote:
After playing with TigerVNC's version of WinVNC for a while, it is
unfortunately too broken on Windows 7 to provide a quick enough solution
for my customer.  However, I wanted to share some of my general findings
regarding the state of Windows VNC servers, in case someone else is
inspired to adopt TigerVNC's Windows server in the future.

We were looking for a WinVNC solution that could be brought up to
TurboVNC's levels of performance without a lot of break/fix work.

TurboVNC:  TurboVNC's WinVNC is the fastest out there (equal in
performance to the TurboVNC or TigerVNC Linux server), but it's still
based on the TightVNC 1.3.10 code base, which doesn't work properly on
W7 or Vista and has a lot of rendering issues on all Windows platforms
(including XP.)  Its usability is marginal due to those issues.

TigerVNC:  TigerVNC's WinVNC is the second fastest but is still only
about half as fast as TurboVNC, even though the Tight encoders in the
two solutions should be performing the same now (something else is
causing TigerVNC's performance to lag-- didn't dig into it to find out
what.)  TigerVNC's Windows server works well on XP but has issues with
W7 (doesn't work at all when run as a service, and even in User Mode,
some windows can't be remotely controlled-- probably all issues related
to W7's new security model.)

TightVNC 2.0.x:  The best usability and the cleanest functionality of
any open source implementation, and it works on modern Windows distros,
but its best performance is unusably slow (~1/40 that of TurboVNC.)

UltraVNC:  Good usability and works cleanly on modern Windows distros,
but it exhibits banding artifacts, and its best performance is about 1/4
that of TurboVNC.

RealVNC 4.6 Enterprise:  By far the best usability and functionality of
any WinVNC solution I tested, but its best performance is 1/3 of
TurboVNC (and it's proprietary.)

In short, there is really no WinVNC solution that is both a solid
solution for modern systems as well as a fast solution.  Bringing
TightVNC up to TurboVNC's levels of performance would require a similar
encoder overhaul to the one I completed in August for TigerVNC (I don't
relish that thought), and TigerVNC would require some additional
optimization work as well as break/fix work to fix the W7 issues--
perhaps not as much of an effort as another encoder overhaul but still
more of an effort than I have the cycles for at the moment.

Given that we're not moving forward with TigerVNC's WinVNC, I have no
objections to eliminating Visual C++ support entirely, and I'll proceed
with doing that if no one else objects (which I assume they don't, since
no one spoke up during our knock-down drag-out debate on the subject.)

DRC

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel

--
Robert Goley

FOSS Implementation Specialist
Toll Free: (800) 338-4984
Local: (770) 479-7933
Fax: (770) 479-4076
www.openrda.com

America's only Free & Open Source fund accounting software company.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel

Reply via email to