Fwd: One TurboVNC Viewer to rule them all

[DRC]

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