Oops. I meant this to go to the TurboVNC lists. Sorry about that. On 10/14/18 8:54 PM, DRC wrote: > This will likely be controversial, but several developments have > prompted the decision to retire the native Windows TurboVNC Viewer in > the next major release of TurboVNC: > > 1. The Windows TurboVNC Viewer, owing to its use of raw Win32 GUI code, > was already difficult to maintain and very difficult to extend. It was > already lacking some major features (most notably, TLS encryption and > built-in SSH tunneling) that would have been difficult and costly to > implement, and no funding has ever emerged to implement those features > or to port the viewer to a modern GUI toolkit (despite actively seeking > that funding for six years.) > For almost every funded TurboVNC Viewer feature that has been > developed since 2012, I have tried to secure funding to implement the > feature in both viewers, but on several occasions, porting a particular > feature from Java/Swing to raw Win32 GUI code led to cost overruns, and > on more than one occasion, I had to eat that cost. I ended up eating a > significant amount of cost (thousands of dollars) on the Xinerama > feature in TurboVNC 2.2, primarily because of the complexity of porting > that feature to the Windows TurboVNC Viewer, so finding a way to > consolidate around the Java TurboVNC Viewer has been in the back of my > mind for over a year. > > 2. Java 11 has made it possible to build custom JREs containing only the > components that the TurboVNC Viewer needs. There are some drawbacks to > this: > a. The need to constantly update the JDK on the build machines in > order to get the latest Java security and bug fixes, and the inability > of users to get those fixes without a new release of TurboVNC. However, > the same limitations would have existed with libssh2 and/or OpenSSL, had > we added built-in encryption to the Windows TurboVNC Viewer. > Furthermore, Homebrew and Chocolatey make it easy to continuously update > the JDK in both the local and CI build environments, and the custom JRE > is embedded into the TurboVNC Viewer in such a way that you can override > it and use an external JRE by setting the JAVA_HOME environment variable. > b. A disk footprint of ~75-80 MB, due to the custom JRE, but this > isn't really that big of a deal except possibly for embedded > environments. Furthermore, this is something like 1/3 of the disk > footprint of a full JRE, so the overall disk footprint of the Java > TurboVNC Viewer on Windows has been reduced, despite the fact that the > overall disk footprint of the Windows TurboVNC Viewer package has > increased (the installer package is now about 30 MB.) > c. No support for 32-bit-only Windows flavors. Thus, the TurboVNC > Viewer for 32-bit Windows will continue to rely on a separate > installation of Java 8, since that's the last long-term release of Java > to support 32-bit Windows. As a result of this limitation, the evolving > TurboVNC 2.3 package for 32-bit Windows will only install on a > 32-bit-only Windows machine, and the installer displays a warning about > the need to also install Java 8. I have successfully installed and used > that package with Java SE 8u152 i586 on Windows XP, thus proving that it > will at least be possible to support legacy Windows systems with > TurboVNC 2.3. > Referring to > https://www.backblaze.com/blog/64-bit-os-vs-32-bit-os, there are still a > lot of 32-bit-only Windows installations out there, but there's a good > argument to be made that most of those installations are on > 64-bit-capable machines. Many of those installations may have in fact > been enabled by Microsoft's insistence on providing a 32-bit-only > upgrade path for all of their modern O/S releases (including Windows > 10), even on systems that support a 64-bit O/S. In technical computing > markets (the markets to which TurboVNC primarily caters), the vast > majority of users have been on 64-bit client O/S's for well over a > decade. nVidia announced the end of 32-bit driver support earlier this > year, and other companies are following suit, so by the time TurboVNC > 2.3 (which may be renumbered to 3.0, depending on how things shake out) > is released, this is likely to be a non-issue. But please correct me if > I'm wrong. > > 3. The new TurboVNC Session Manager-- which automatically connects to a > TurboVNC server machine using SSH, displays the list of running TurboVNC > sessions under a particular user account, and allows the user to connect > to or kill any of those sessions or to start a new session-- is > GUI-intensive, and implementing that feature in the Windows native > TurboVNC Viewer would have forced me to eat cost on the project. I'm > not in a position to do that right now. > > 4. The elimination of Java Web Start in Java 11 means that any notion of > a zero-install Java TurboVNC Viewer is now deprecated. Furthermore, the > elimination of a separate JRE in Java 11 means that deploying the Java > TurboVNC Viewer with a separate installation of Java makes much less > sense now. Thus, a standalone viewer is the only way to move any of the > TurboVNC Viewers forward, and there is no funding to implement the > necessary features in the Windows TurboVNC Viewer or to make it > cross-platform. Migrating to the Java TurboVNC Viewer allows us to > continue to support Java Web Start for as long as Java 8 is available, > while also allowing a migration path away from it, all with the same > code base. > > In short, this migration effort has improved our product in the > following ways: > - Lower cost for funded development of viewer features > - Lower maintenance cost for the product in general, meaning that the > TurboVNC General Fund will not get exhausted quite as quickly each year > - Access to all of the features in the Java TurboVNC Viewer (including > built-in SSH tunneling and encryption, as well as the new TurboVNC > Session Manager) without the need to install a JRE (except on 32-bit > Windows) > - Reduced disk footprint for the Java TurboVNC Viewer, since a full JRE > is no longer required (except on 32-bit Windows) > > The evolution of the TurboVNC Viewer was complicated. Originally, our > project was little more than TightVNC 1.3.x with a high-speed JPEG > codec, so we inherited all of the TightVNC viewers-- a native Windows > viewer written using raw Win32 GUI code, a rudimentary native X11 viewer > written using Xt/Intrinsics widgets, and a rudimentary Java/AWT viewer > that worked only as an applet. Brian's work back in 2012 to port the > TigerVNC Viewer to Java, then our combined effort to add various unique > features from the Windows TurboVNC Viewer to his viewer, produced the > Java TurboVNC Viewer. The early development of this viewer was funded > by Santos, in the context of a project to produce an Android TurboVNC > Viewer, and later by Altair, in the context of a project to produce a > feature-rich browser-based TurboVNC Viewer. Since then, the Java > TurboVNC Viewer has evolved considerably. It made sense very early on-- > in TurboVNC 1.2, when the Java TurboVNC Viewer was introduced-- to use > it instead of the Xt TurboVNC Viewer on Mac, since XQuartz had > performance issues and since installing a JRE was no more difficult than > installing XQuartz. As the Java TurboVNC Viewer gained more features > and optimizations (including deep performance optimizations that worked > around unnecessary buffer copies in the Java 2D implementation for X11, > as well as a low-level library-- the TurboVNC Helper-- for twiddling X11 > stuff that isn't possible to twiddle from Java), it made sense to retire > the Xt TurboVNC Viewer in TurboVNC 2.0. Similarly, with the ability to > use the Windows/Java TurboVNC Viewer without a JRE, it finally makes > sense to consolidate our product into a single VNC viewer, rather than > the three VNC viewers we started with. The next evolution is likely to > be another browser-based viewer, written using WASM this time, so as > much as anything, I had to clear the plate the make room in the project > for that. > > There are, however, some features that need to be implemented in the > Java TurboVNC Viewer in order for it to achieve feature parity with the > Windows TurboVNC Viewer. I have created a new GitHub milestone to track > these: > > https://github.com/TurboVNC/turbovnc/milestone/4 > > Please let me know if anything needs to be added to that. Two features > that aren't mentioned are: > > 1. RFB file transfer support, but this comment expresses my feelings > regarding that feature: > https://github.com/TurboVNC/turbovnc/issues/97#issuecomment-429677443 > I'm happy to upgrade the file transfer feature in the Windows TurboVNC > 2.2 Viewer so that it supports UltraVNC and TightVNC v2 servers, > assuming someone is willing to pay for the day of labor that would > likely require, but otherwise I don't have a lot of interest in this > feature, nor does the community. > > 2. Bump scrolling, which I'm also happy to implement in the Java > TurboVNC Viewer if my labor is funded, but otherwise it's also not very > interesting. > > You can test drive the new viewer in the dev/2.3 evolving pre-release build: > https://turbovnc.org/DeveloperInfo/PreReleases > > Share and enjoy, > DRC >
-- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/b0ac6d5b-c7cd-3b47-0754-9078281537e0%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
