This is composed largely of ad-hoc extracts from VNC mailing list notes. It is also almost entirely Windows VNC oriented, due to my focus and knowledge base. My starting point for information searches on VNC is always the ORL VNC page:
http://www.uk.research.att.com/vnc/intouch.html
You can also sign up for the mailing list from there.
Occasionally it is more convenient to have the server make the connection to a client; if the server has a dynamic IP, this may be the only way to do it.
Here's the process.
Let's say we have a machine at address 192.168.1.1, Client1, which wants to
"take over" Server1.
(1) Start VncViewer on Client1 with the "-listen" switch, like:
vncviewer -listen
(2) On Server1, make sure that WinVNC is running as a service if possible; it
needs to be running already for this to work. If not, then she just starts it
the normal way. Make sure it's already started before going to Step 3.
(3) On Server1 you just run Winvnc with the "-connect" option. If Server1 is
typically used only to connect to Client1, you may want to make a shortcut
something like this:
"C:\Program Files\ORL\VNC\Winvnc.exe" -connect 192.168.1.1
This procedure was developed by Floyd Russell and recently posted by him in the VNC mailing list. This is the best general method to use when trying to make sure that VNC is installed as a service and ensure that a password is configred both for your sessions and when logging in with no one on console.
If done on a clean install, I have so far always seen this work.
"1. Install VNC
2. Install VNC Service through Start->Programs->VNC->Administrative
Tools->Install WinVNC Service
3. Run Start->Programs->VNC->Run WinVNC(AppMode)
4. Enter your password, this is for the current user.
5. Start->Programs->VNC->Administrative Tools->Show Default Settings
6. Enter your password, this is for the local machine
7. Close WinVNC
8. Start WinVNC Service
You may need to start the service helper if you want to modify settings of
the winvnc instance running. This problem is due to the way Terminal
Services operates, since you are working in a virtual desktop."
In my experience, this also seems to be a really good way to make a fussy WinVNC install work on Win2K whether you are installing remotely or not. Also note that this seems to work well for stable installs on Windows XP.
The Olivetti Research Labs facility in Cambridge was closed 2002 April 24 by AT&T, thus ending business at the facility which gave birth to VNC.
Fortunately, the website for VNC has not been shut down, and will continue to be maintained (along with the VNC mailing list) for the foreseeable future. Since VNC has a large user base including active developers and open source code, this is not nearly the crisis it would be for a closed commercial product.
In fact, it may afford some of the original developers opportunities to pursue more work on VNC. Here's an extract from a post by Tristan Richardson to the VNC list:
"......the creators of VNC are planning a venture to independently support
and develop VNC as an ongoing open source project. You haven't heard much
from us recently because we've been busy with other projects such as the
Broadband Phone, but now that we have the opportunity :) we're back on the
case."
VNC will be re-hosted at Cambridge fairly soon. Please note that anytime such a move is made there is always some chance of minor outages in service during the switchover; so if the server or list appears to be unavailable for a short period of time at some point, that should be the cause. It doens't mean someone pulled the plug... :)
and set it to 1.
Because you have discovered the tradeoffs between bandwidth consumption and latency. This was put best by Peter Hutnick in a post to the VNC mailing list:
"...be aware of the difference between bandwidth and latency. For instance, on a dedicated 100M link VNC "feels" the fastest with "raw" encoding, which uses the /most/ bandwidth. This is because the server and the viewer don't waste time on encoding/compression to reduce bandwidth use. [On the other hand], over a slow link the tighter the encoding the faster it feels, because you aren't waiting as much for updates to trickle through the pipe."
16tX5H-0000BM-00 for vnc-list@uk.research.att.com; Fri, 05 Apr 2002 18:01:07 +0100
http://www.uk.research.att.com/vnc/winvnc.html
The documentation is very complete. If you have a question about VNC configuration, it almost certainly is on this page in the section on the Windows VNC registry settings. Read it carefully: unlike most OEM manuals, this is very compact and precise. More than once I have found what I thought was a problem or error in the VNC configuration, only to discover on careful reading that it was indeed covered in the VNC documentation.
This is due to the design compromises VNC had to make to work in a manner structurally identical on Microsoft and Unixish operating systems. The problem is that you have a default password which has not been changed if you changed a user setting. Here is a post I made to the VNC mailing list on this topic:
These are stored within the registry under:
HKEY_CURRENT_USER\Software\ORL\VNCviewer\MRU
The following VBScript can be used to automatically clear this out when it is run.
'rmVncMru.vbs
Set oSh = WScript.CreateObject("WScript.Shell")
oSh.RegDelete "HKCU\Software\ORL\VNCviewer\MRU\"
Tim Pfaltzgraff, one of the regular contributors to the VNC mailing list,, suggests the following as a general fix for this problem.
"Make sure that the following updates are installed:
1)
Win98se Shutdown Supplement - MS KB Q239887
2)
Win98se Mapped Drives Shutdown Update - MS KB Q260067
Each of these are only 450-505 kb to download, and are harmless if not
needed, but can help greatly if that's what the system needs. My
desktop system is a Win98se system, and I run the WinVNC server without
shutdown problems."
Luptak Miroslav (HP-Slovakia) has done some experimentation and determined that it appears to use 5500.
Another procedure posted by Luptak Miroslav:
- execute "vncviewer /listen" on your PC
- on the "server" machine, execute "ssh -L5500:127.0.0.1:5500 your_pc"
- on the "server" machine execute "winvnc -connect 127.0.0.1"