WinVNC - The Windows NT VNC server
WinVNC is a VNC server that will allow you to view your Windows desktop from
any VNC viewer. Because Windows in its present, standard incarnation, only supports a
single graphical user being logged in at any one time, WinVNC makes the existing desktop
of the PC available remotely, rather than creating a separate desktop. It is only fair to
emphasise this: VNC does not make an NT machine into a
multi-user server in the same way that Citrix-based software, for example, does. A single
NT machine can therefore be accessed by multiple users, but if they all connect at the
same time they will all see the same desktop!
WinVNC will run on Windows 95, Windows NT 4.0 and on any future Win32-based systems,
without the need to replace any system files or run any OS-specific versions of the
program. It is a standard application that can be run from the Start... menu and closed
down just as easily.
WinVNC can now also be run as a service, which means that you can log in remotely, do
some work, and log out again. This is still under development, and has some rough
edges, but is still very useful. See below for more details.
And, of course, WinVNC is free. We hope that making the source code available will
enable programmers who know more about the internals of Windows than we do to suggest
improvements to any and all aspects of WinVNC.
WinVNC is fairly simple to install and even easier to use. Installation involves the
- Run the WinVNC setup program.
- Optionally, install the default VNCHooks registry settings by selecting Install Default
Registry Settings from the WinVNC folder in the Start menu. This will install the default
hooks settings, which are tweaked to cope with some common, uncooperative applications,
such as the clock. See later for more information about the registry settings.
- WinVNC can now be run from the Start menu. Alternatively, you can use the
Start->Settings->Taskbar menu to add a shortcut to your Startup group, which will
cause WinVNC to be run every time you log in.
On starting, WinVNC will add a small, green version of the VNC icon to the system task
bar. Clicking on this icon with the right mouse button will cause a menu to be displayed,
with the following options on it:
- - This will cause the
Properties dialog to be displayed, allowing the user to change various WinVNC parameters.
- - This will disconnect
all currently connected clients from the server.
- - Shutdown the server.
The following options are available from the Properties dialog.
- - The server normally accepts
direct, socket-based connections from the vncviewer program. Clearing this tick-box
disables direct connection to WinVNC, so that only the CORBA interface used by our
internal version may be used to start a connection. (See ORL
internal version info). For the public version, clearing this will disable any
- - This allows the user to specify the
display number which the server will use. There is normally no need to change this
from the default of zero.
- Auto - This tick box indicates to WinVNC
whether it should use the display number specified in the Display Number box, or whether
it should use the first display number not already in use on the server machine.
- - Incoming connections must be authenticated to
verify that the person connecting is allowed to connect to this machine. This text box
allows your password to be specified for authentication.
- - Any new
incoming connections will be able to view the screen but not send any input.
Note that clicking in a window will generally cause it to be updated, so if you
have certain applications which don't update very well, try this!
- - Some
applications are incompatible with the methods currently used in WinVNC to trap screen
updates. For this reason, it is sometimes useful to be able to poll the entire screen in
order to check for changes, sacrificing performance for accuracy.
- - Polling only the currently
selected window for changes is less CPU intensive than full-screen polling and often gives
similar results, for example when using the Command Prompt, which is not normally
compatible with WinVNC.
A variation on Poll Foreground Window, this option causes the window under the mouse
cursor to be polled for changes. Both options may be enabled simultaneously if required.
When this option is set, the only windows which will be ever be polled are Command
Prompts. This works well in conjunction with Poll Window Under Cursor, to use polling only
when the cursor is over a console window.
When this option is set, the screen will only be polled for updates when a mouse or
keyboard event is received from the remote client. This is provided for low bandwidth
networks, where it may be useful to control how often the screen is polled and changes
The user's settings are saved into the user-specific section of the registry when
WinVNC quits, meaning that they will be used next time you run WinVNC.
WinVNC - Advanced Settings
As of Version 3.3.2 R2, some extra options have been added to WinVNC for use primarily
by system administrators, to tailor the server's behaviour to meet their particular needs.
The options are DWORD values which can be set in the system registry, under the
By default, all WinVNC servers will not accept incoming connections unless
the server has had it's password field set to a non-null value. This restriction was
placed to ensure that misconfigured servers would not open security loopholes without the
user realising. If a server is only to be used on a secure LAN, however, it may be
desirable to forego such checking and allow machines to have a null password.
Setting this registry value to zero will disable null-password checking by WinVNC.
By default, all WinVNC servers disallow any vncviewer connections from the same machine.
For testing purposes, or, potentially, when using multiple instances of WinVNC on
Windows Terminal Server, this behaviour is undesirable. Setting this registry entry
to 1 will cause local-loopback connections to be allowed. Setting it to zero will
filter out such connections.
Run-time logging of all internal debug messages is now supported. Log data may be output
to a file or a console window (or the MSVC debugger if the program was compiled with
debugging active.) Two registry keys are used:
DebugMode indicates which logging methods to use,
[1 = MSVC debugger]
2 = Output to log file Winvnc.log in the WinVNC directory
4 = Output to a console window, displayed on-screen
Any combination of the above values may be used. e.g. DebugMode=6 will cause output
to be sent both to the WinVNC.log file and to the a console window on the desktop.
DebugLevel indicates how much debug information to present. Any positive integer
is valid. Zero indicates that no debugging information should be produced and is the
default. A value of around 10-12 will cause full debugging output to be produced.
By default, all WinVNC servers will disconnect any existing connections when an incoming,
non-shared connection is authenticated. This behaviour is undesirable when the
server machine is being used as a shared workstation by several users or when remoting a
single display to multiple clients for vewing, as in a classroom situation.
ConnectPriority indicates what WinVNC should do when a non-shared connection is
0 = Disconnect all existing connections.
1 = Don't disconnect any existing connections.
2 = Refuse the new connection.
VNCHooks - Advanced Settings
WinVNC uses a special library, VNCHooks, to hook into the other running applications
and retrieve notifications of areas of the screen being changed. The VNCHooks
library uses the messages sent to visible Windows to decide which areas need considering
for update. Not all applications use the same method of updating the screen, so you can
tweak the method used by WinVNC for particular applications by editing the registry. All
the entries listed can be found under
When a window recieves a message, (WM_PAINT), indicating that it should repaint itself, it
is possible to find out precisely which regions have changed, so that WinVNC need only
scan those for potential updates,increasing efficiency. However, this can cause graphical
glitches occasionally, particularly when an application scrolls the contents of its
window, in which case only the revealed section of the window is marked as needing to be
updated. If these glitches prove to be a problem then edit the <appname>\use_GetUpdateRect
entry in the registry. A value of one indicates that this optimisation will be used, while
a value of zero indicates that it will not.
A number of Windows applications, most notably the Clock program, use WM_TIMER events to
trigger updates to their displays, rather than WM_PAINT messages. By default, timer
messages are not used to notify WinVNC of potential updates, since many programs use timer
events for purposes other than updating the screen. As a result, the clock and a few other
applications don't normally update correctly under WinVNC. The fix to this is to edit the <appname>\use_Timer
entry in the registry. A value of one indicates that WM_TIMER messages will trigger WinVNC
updates, while a value of zero indicates that they will not.
Some Windows applications write characters directly to the screen when a user types into a
window, rather than using WM_PAINT messages to cause the text to be redrawn. To fix this,
WinVNC can scan the window every time a key is pressed, in order to catch the change. To
set this value for a problem application, edit the <appname>\use_KeyPress
entry in the registry. A value of one indicates that key presses will cause updates, while
a value of zero indicates that they will not.
- , ,
Some Windows applications update the display directly in response to mouse clicks, without
using intermediate WM_PAINT messages, for example. In order to catch such updates, it is
necessary to trigger WinVNC to update the relevant window whenever the left mouse button
is released. To set this value for a problem application, edit the <appname>\use_LButtonUp
entry in the registry. A value of one indicates that left-button clicks will cause
updates, while a value of zero indicates that they will not. The same rules
apply to the middle and right buttons using the appropriate value name.
The VNCHooks library catches messages sent to windows before they are dealt with
by the window. As a result, sending an update message to WinVNC to indicate the potential
change can result in WinVNC sending the updated area to the client before it has actually
been redrawn by the application! This is a common problem, especially on multiprocessor
versions of NT, so deferred updates are used by default. Deferred updates are handled by
posting a custom message back into the window's own message queue rather than posting to
WinVNC directly. By the time this custom message is seen again by the VNCHooks library,
the message that caused it will have been handled and the update can then be forwarded to
WinVNC without danger of being handled prematurely. A few programs don't handle these
extra messages in their queue very well, so this optimisation is optional. It can be set
by editing the <appname>\use_DeferredUpdate entry in the registry.
A value of one indicates that deferred updates will be used, while a value of zero
indicates that they will not.
Running WinVNC as a service
WinVNC can now be made to run as a service process under both Windows NT and Windows
95, by following the instructions outlined below. The service support is still in
the early stages of development, and the following 'features' should also be pointed out:
Windows NT 'features':
- There will be one password for the machine, rather than one per user.
- The system tray icon is not always correctly displayed, so you won't always be able to
tell whether someone else is connected except by the fact that things work more slowly.
Windows 95 'features':
- Whether or not the VNC password is set per-machine or per-user depends on the settings
in the Passwords section of the Control Panel. If Win95 is set to use a different
set of registry values for each user then when a user logs in, the password will change
from the per-machine VNC password to that user's VNC password. If Win95 is set to
use the same settings for all users then the per-machine VNC password will always be used.
General features for both Windows NT and Windows 95:
- Anything which causes the Windows VNC server to change screen resolution will also cause
all viewers to be disconnected, and you'll need to reconnect.
- When WinVNC is running as a system service, no user-level copies can be run at the same
Here's how to get it running as a service, assuming you've already installed it.
- Windows NT : You need to have administrator privileges on the local
machine, so log on as administrator if your account doesn't have these.
- Open a Command Prompt and cd into the directory into which you installed
C:\> cd "\Program Files\ORL\VNC"
- Install the WinVNC service using the -install option. A dialog box will appear to
indicate the success or failure of the operation.
C:\Program Files\ORL\VNC> winvnc -install
Windows 95 : The WinVNC service is now running and is installed to run
whenever the system boots up into Windows 95.
Windows NT : The WinVNC service is installed and set up to run whenever
the machine is booted into Windows NT but IS NOT YET RUNNING! You can run and
stop the WinVNC service using the control panel, or using "net start" and
C:\> net start winvnc
- If you wish to change the WinVNC settings (eg. password) when it is running as a service
and is therefore not visible on the taskbar, you must use the -settings option.
Open a command prompt and move into the directory into which you installed WinVNC, as
described in part 2) above. Use the -settings option to cause the service to display
its Properties dialog.
C:\Program Files\ORL\VNC> winvnc -settings
NOTE : Windows NT : The settings used by the winvnc service are the
Default user settings and are stored per-machine, rather than on a per-user basis as is
done when running WinVNC normally. Access for all users will be controlled by the one
NOTE : Windows 95 : If Win95 has been set to use different settings for
each user then the settings used are those of the currently logged in user. If no
user is logged in or Win95 is set to use the same settings for all users then the settings
used are the Default user settings and are stored per-machine, rather than on a per-user
basis as is done when running WinVNC normally. (Under Win95, pressing Cancel on the
login dialog gives access to the Default user settings.)
- When you wish to install a new version of WinVNC or simply wish to remove WinVNC from
your machine, you must first remove the service from the system, using the -remove
Open a command prompt and move into the directory into which you installed WinVNC.
Use the -remove option, which will automatically stop the service and then remove
it, and show a dialog box to indicate the success or failure of the operation.
C:\Program Files\ORL\VNC> winvnc -remove
NOTE : Failure to remove the service usually indicates that it was not installed in the
- The full command-line options available are as follows (for version R19 and later). You
probably won't need anything other than those listed above unless you're a real VNC
-run Causes WinVNC to run normally & ignore
rest of command-line.
-install Installs the WinVNC service and continues reading the
-remove Removes the WinVNC service and continues reading the
-settings Tells a running copy of WinVNC to show its Properties box.
-kill Kills a running copy of WinVNC.
-about Tells a running copy of WinVNC to show its About box.
If no options are given then WinVNC runs normally. Multiple option may be given, so, for
example, to upgrade from a running copy of WinVNC to a new one, you could use:
WinVNC_new -remove -install
which will stop & remove the old copy & install the new one as a service, or
WinVNC_new -kill -run
which will stop the running copy & run the new version normally.
Running on other Win32 systems
WinVNC runs fine on NT3.51 but the absence of a system tray means that the Properties
dialog cannot be accessed. In addition, Ctrl-Alt-Del from clients cannot be
correctly interpreted under NT 3.51, limiting WinVNC's usefulness when run as a service on
this platform. It also runs on NT5 beta.
If you have a choice we recommend NT4.0 with the latest service packs installed.
go back to documentation