OSXVnc2: Enhanced OSXVnc

Developmental Release: Help wanted!

WARNING:

This version does not include a UI for setting the VNC password, and will default to using _no password_, a big security risk if you are accepting incoming connections.

You need to figure out how to make authentication work, on your own, use outgoing connections only, or use it behind a firewall and other security measures.  caveat emptor!

This developmental release is useful for people who know what they're doing, but is mainly here so that interested developers can help build on this. If you're interested, I have lots of ideas on how to make this most useful to the VNC community, and would like to discuss them with anyone else who is interested.

I can be contacted at stevek@stevek.com.

This code is an enhanced (in some ways, "dehanced" in others). version of OSXVnc, currently called "OSXVnc2".

The predecessors of this version of OSXVnc are:

The original X11 Xvnc, from Att labs Cambridge (aka olivetti, etc).
Dan McGuirk's OSXVnc-server (the server-half of his code, not the Java front-end).
Another OSXVnc hack of unknown origin, who added tightvnc encoding (used as a template to add it here)
HexoNet's x0rfbserver, by Jens Wagner
Const Kaplinsky's TightVnc distribution.
Others who have contributed to these or others over the years.

And our own changes.



Basically, this code came from Dan McGuirk's OSXVnc-server code, and did the following:

• Adds support for reverse connections (Server connects to client).
• Merged x0rfbserver's XScanner code, and backported to Unix (Linux only tested, some X11 race conditions remain, only supports 32bpp displays, etc).  This required splitting platform-independent and platform-dependent code, ported XUpdateScanner from C++ to C, etc.
• Added support for rich sub-desktop sharing (i.e. you can share either your whole desktop, or a smaller rectangle thereof.  This Shared area can be selected either by dragging and moving a selection rectangle on-screen, or choosing a UI Element, and the server will follow that element as it moves and resized on the screen (restrictions apply).  This UI is only built for OSX at the moment)
• Added support for tight, zlib, and zlibhextile encodings.
• Purpose-built UI for MacOSX (connection status indicated in Dock, connect dialog, and lots of UI for sub-desktop sharing).

• This version does not include a UI for setting the VNC password, and will default to using _no password_, a big security risk.  You need to figure out how to make authentication work, on your own, or use it behind a firewall and other security measures.  caveat emptor!
  
• This code can also be built as "LiveShareHost", which includes some different Branding and default options.
• This code has only been tested significantly against the TightVNC java VncViewer code; for example, until recently, it just blindly assumed that clients supported NewFBSize.  It now checks for client capabilities, but doesn't handle them as optimally as it could.
  
• This code uses ProjectBuilder and gcc for building on Mac OS X, and a simple Makefile for building under X11 Unix.
• The subdesktop Element Sharing code uses Jaguar (Mac OS X 10.2) APIs under MacOSX; you need Jaguar to build with this support.  However, the relevant APIs are manually weak-linked, so the resultant binary should run fine under OS X 10.1.  (untested under 10.0).
• The X11/Unix support is pretty untested, and early tests show at least a race condition in X11 handling somewhere, probably due to the multithreaded access to the X11 socket, etc.

• First pass: Relatively straightforward stuff
• Add proper support for passwords!
  
• Merge codebase with libvncserver; make libvncserver a true library, and link front-end code against it.
• Add a UI for Unix, with similar functionality to the OSX UI
• Add better support for "traditional" VNC Host usage (i.e. allowing incoming connections, possible built-in webserver, controlling incoming connections, persistent "server modes", etc).
• Add cursor position/shape stuff to OSX side.
• Lots of performance tuning on Unix side (i.e. tune polling algorithm, or integrate some notification/observer interface to get positive notification from XServer on bitmap changes).
• Implement CopyRect detection:  This can be quite expensive, but a smart algorithm might be able to detect many simple CopyRect optimizations (i.e. Terminal window scrolling would be pretty easy, browser scrolling, etc).
• Second pass: Integrate the various Win32 hosts, and the "traditional" X11 host into a single codebase.
• "Traditional" X11 server (i.e. uses a separate X11 display, not a display shared with a real screen.  This code is derived from that code, so it could be done).
  
• Win32 TightVNC server, as improved (currently, this is an entirely separate codebase, all in C++, etc.  It would be more difficult to merge these, but possible).