To be honest, I don't think there's a lot of traction for WinVNC in this project, and there probably won't be unless someone else adopts it like Brian has done with the Java code. Both Cendio and myself are focused on the multi-user application-as-a-service model rather than on the remote access model, which means that we are focused largely on Xvnc and don't really have a stake in WinVNC, the VNC X11 module, or x0vncserver. WinVNC really needs to be adopted by someone who has a stake in it and will thus be able to test it constantly and give it the attention it needs to stay healthy. Part of my decision not to go forward with it for my customer was the fact that I wouldn't have a stake in the TigerVNC Windows server outside of their contract, and thus once the customer was happy with it and the contract was over, I'd be left in a position of maintaining code I don't care about for free.
My strengths are largely related to high-performance computing, image processing, 3D, and streaming video, so while I have developed skills around tracing down esoteric issues in old X server code bases over the years, that's not really what I want to be doing, nor is tracing down issues with Windows 7 security models. If I were going to develop a high-speed WinVNC solution myself, I'd choose the path that plays the most to my strengths, which is bringing in the TightVNC 2.0.4 code base and optimizing it in the same way I did with TightVNC 1.3.10. That's a fairly monumental undertaking, though, since the codecs have diverged somewhat, and optimizing TightVNC 2 would be about the same level of effort as optimizing the TigerVNC server (which was easily a 100-hour project.) I don't think trying to marry TightVNC with TigerVNC would save any time vs. simply fixing TigerVNC, but both would be fairly big projects, probably on the same order as overhauling the TightVNC encoder. >From my point of view, it often seems like the things that are the most difficult to work with vis-a-vis the TigerVNC code base-- support for multiple X servers, the X11 module, GnuTLS support, NLS, Windows compiler issues, etc.-- are things that my users largely don't care about. They definitely don't care about WinVNC, because we use an entirely different solution for Windows apps (running them inside of VirtualBox running inside of VirtualGL running inside of Xvnc, since WinVNC is not a multi-user solution.) I guess what I'm saying is that I'm not in a good position to own the WinVNC portion of the code, and unless someone else steps forward to own it in the long term, I'd rather we just abandon it as opposed to pretending it works. Right now, it seems like we're maintaining the build only because we hope to attract someone to work on it. As you pointed out, the modifications required to make it work on modern Windows platforms are fairly extensive. Performance work always seems the most straightforward to me, so to me, it seems easier to take a code base that already works on W7 and optimize it rather than taking an optimized code base and making it work on W7. That's just me, though. On 11/7/11 4:20 PM, Robert Goley wrote: > 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 ------------------------------------------------------------------------------ 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
