Unpaid computer tech support for relatives is not a popular topic among geeks. It is very much a reality, however, specially in Indian communities with extensive extended families like mine. Some of the griping is churlish considering all the favors your family cheerfully does for you, and we probably have it better than MDs who are constantly bombarded with requests for free medical consultations.

At first sight, I would be better off if my relatives had the good sense to ditch Windows and get a Mac instead, but that would in fact compound the problem because I would get even more calls for help from people who are having a hard time dealing with very basic issues on an unfamiliar platform. Mac OS X may be better integrated and secure than Windows, but contrary to popular opinion it is not that much less crash-prone. All computers are unnecessarily hard to use in the first place. I doubt very much the computer industry will mend its ways and put human-centered design first, more likely than not the problem will be “solved” by the progressive eclipse of generations born before widespread computing, the rest of us having perforce adapted to these flawed tools.

A big part of the problem is doing “blind” support over the phone where you don’t see what is going on, and often the person in front of the screen is not technical enough to know what is significant and how to give you a useful and actionable description of what is on screen.

To its credit, Microsoft added remote assistance functionality in Windows XP. Explaining to users how to activate it is a challenge in itself, however, and in any case you need another Windows XP machine to provide the support. I still run Windows 2000 in the sole PC I have (used exclusively for games nowadays) and it makes such a racket I am almost viscerally reluctant to boot it up.

The best solution is to use virtual network computing (VNC), a free, cross-platform remote control protocol originally invented by the former Olivetti-Oracle-AT&T labs in Cambridge, UK. I often use VNC to take control of my home Mac from my office PC or my MacBook Pro. Indeed, VNC is integral to Apple Remote Desktop, Apple’s official remote management product for large Mac installations. There are even VNC clients available for PalmOS and Windows CE so you could remote control your home computer from a Treo. Having VNC running on the ailing PC would allow me to troubleshoot it efficiently from the comfort of my Mac.

Unfortunately, there is still a chicken-and-egg effect. I once tried to get an uncle to set up UltraVNC on his PC and do a reverse SSH forwarding so I could bypass his firewall. It took the better part of an hour, and barely worked. Surely, there has to be a better solution.

One such solution is Copilot, a service from Fog Creek software that repackages VNC in a form that’s easier to use. It is somewhat expensive, however (although that can be seen as a feature if the people calling for help have to pay for it and thus have an incentive to moderate their requests).

Another one that shows some promise is UltraVNC SC, a simplified version of UltraVNC that is designed for help desks (here is a more friendly walkthrough). Unfortunately, it shows a very clunky dialog that makes sense in a corporate help desk setting, but is too confusing for a novice user, and it uses UltraVNC extensions that are not compatible with most other VNC clients like the one I use most, Chicken of the VNC.

In the end, what I ended up doing was to take the source code for the full-featured UltraVNC server, rip out all the user interface and registry settings from it, and hardcode it to open an outgoing connection to my home server alamut.majid.org on TCP port 5500. There isn’t anything on the server listening on port 5500 by default, but I can open a SSH connection to it from anywhere in the world and use SSH reverse port forwarding to connect port 5500 to wherever I am. This neatly sidesteps the problem of firewalls that block incoming connections.

The resulting executable is larger than SC, but still manageable at 500K (vs. 950K for the full version), and requires no input from the user beyond downloading it and running it, thus triggering all sorts of warnings. It’s not good practice to teach users to download and run executables, but presumably they trust me. After the VNC session is finished, the program simply exits (as evidenced by the disappearance of the UltraVNC eye icon from the toolbar

If you want to use a setup like mine, it’s easy enough for a technically inclined person:

1. You could download my executable at majid.org/help, open it in a hex editor (or even Emacs), search for the string alamut.majid.org and overwrite it with the name of the machine you want to use instead (I left plenty of null bytes as padding just in case). Make sure you are overwriting, not inserting new bytes or shrinking the string, as the executable won’t work correctly otherwise.
2. Or you could download the modified source code I used (UltraVNC is a GPL open-source project, so I am bound by the license to release my mods). Edit the string host in winvnc/winvnc/winvnc.cpp (you can also change the reverse VNC port from its default of 5500 if you want), and recompile using the free (as in beer) Visual C++ 2005 Express Edition and the Platform SDK. My Windows programming skills are close to nil, so if I could do it, you probably can as well.

To use the tool, put it up on a website, and when you get a request for help, SSH into the server. On UNIX (including OS X), you would need to issue the command:

ssh -R5500:127.0.0.1:5500 your.server.name.com

Please note I explicitly use 127.0.0.1 rather than localhost, as the former is always an IPv4 address, but on some systems, localhost could bind to the IPv6 equivalent ::1 instead.

On Windows, you will need to set the reverse port forwarding options in PuTTY (or just replace ssh with plink in the command-line above). After that start your VNC client in listen mode (where the VNC client awaits a connection from the server on port 5500 instead of connecting to the server on port 5900). You can then tell the user to download the executable and run it to establish the connection.

Some caveats:

1. The leg of the connection between the PC and the server it is connecting to is not encrypted
2. Depending on XP firewall settings, Windows may ask the user to authorize the program to open a connection
3. At many companies, running a program like this is grounds for dismissal, so make sure whoever is calling you is asking for help on a machine they are authorized to open to the outside.

I hesitated to make this widely available due to the potential for mischief, but crackers have had similar tools like Back Orifice for a very long time, so I am not exactly enhancing their capabilities. On the other hand, this makes life so much easier it’s worth sharing. Helping family deal with Windows will still be a chore, but hopefully a less excruciating one.

Update (2007-03-23):

You can make a customized download of the executable targeting your machine using the form below. Replace example.com with whatever hostname or IP address you have. If you do not have a static IP address, you will need to use a dynamic DNS service like DynDNS or No-IP to map a host name to your dynamic IP address.