I would suggest using the UltraVNC Server with the TigerVNC Viewer. TigerVNC is mainly developed by people who have a vested interest in the Unix TigerVNC Server but not in the Windows TigerVNC Server, so the latter has received little attention in recent years. The principal developers chose to separate the Windows TigerVNC Server into its own package but leave it in the distribution in hopes of encouraging someone to take over maintenance of it, but that hasn't happened. It would take a lot of work to bring the Windows TigerVNC Server into compliance with modern Windows distributions, and other open source Windows VNC server projects (UltraVNC and TightVNC, namely) have already done that work. The UltraVNC Server now contains the TurboVNC performance enhancements, as does TigerVNC. The Windows TightVNC 2.x Server has a better interface than UltraVNC, IMHO, but it is unfortunately a lot slower.
DRC
To wax a bit more philosophical/historical, all of these projects had a common root in either TightVNC v1.3.x or RealVNC v4, both of which had five distinct code bases:
- A Un*x VNC server (Xvnc)
- A Windows VNC server (WinVNC)
- A Un*x VNC viewer with a GUI based on the raw X11 or Xt API
- A Windows VNC viewer with a GUI based on the raw Win32 API
(AKA "Petzold" code, named after the guy who wrote the canonical
Win32 API textbook in the late 1990s)
- A primitive Java viewer applet with a GUI based on AWT
(pre-Swing)
There is a through-line from the RealVNC
v4 servers to the TigerVNC servers, from the TightVNC v1.3.x
Un*x server to the TurboVNC Server and LibVNCServer, and from
the TightVNC v1.3.x Windows server and viewer to UltraVNC.
However, all of those projects have, over the years, naturally
sorted themselves into their respective niches. The WinVNC
servers in TightVNC v1.3.x and RealVNC v4 used screen scraping
techniques that, to the best of my recollection, stopped working
after Windows XP. UltraVNC chose to focus solely on Windows, so
they kept abreast of changes in the operating system and
accommodated those changes in their screen scraper. TightVNC
did that as well, and they also completely refactored their code
base in v2.0 so that it no longer contains any code from
v1.3.x. TurboVNC shipped a WinVNC server for a while, but we
stopped doing so about 10 years ago (around the time that our
WinVNC server stopped working with new Windows releases.) I
contributed the performance enhancements from the Windows
TurboVNC Server to UltraVNC and now simply direct those desiring
a Windows server to the UltraVNC web site. A modern, updated
Windows TigerVNC Server could potentially take advantage of the
protocol enhancements in TigerVNC (the RFB flow control
extensions, for example) and thus perform better than UltraVNC.
However, the effort involved in updating the TigerVNC screen
scraper is probably a lot more than the effort involved in
porting TigerVNC's protocol enhancements to UltraVNC. (Someone
correct me if I'm wrong.)
DRC