I am writing because I just tried UltraVNC and returned to TightVNC. I thought I'd put my thoughts here for review (and criticism) by everyone.
I have watched UltraVNC's progress with interest. I like the way it looks and hope to (one day) use it instead of TightVNC. Hopefully that will be soon.
I have a home network. It is comprised of several computers on a Linksys router to allow me to have lots of computers which all use my DSL line. All of these computers are doing something and the only way for me to work with them is via VNC. After looking at all of the VNC programs I could find and having downloaded all of them and tried installing them all - I chose TightVNC because of its ease of installation and that once installed it is immediately usable. Also, if need be, TightVNC can be uninstalled and then you can continue to use the system afterwards without any other interruption. These two things (easy of install and uninstall) is what makes it so appealing to me and that is what I want to talk about here (mainly).
In order to install any kind of VNC software - you have to be able to get on to the system itself. To do so I used RDP. "Why?" you ask, would I use VNC over RDP? Well, there are problems with RDP that VNC does not have. Namely, if you have multiple OSs (like XP Pro versus Vista Home) or if one of the machines doesn't even support RDP (like Vista Home), then you have to use something else - like VNC.
So I needed something that was a "Load-N-Go" program. TightVNC is that kind of a program. Here is where the first problem occurred with UltraVNC. If you are logged in via RDP to a system, UltraVNC says "You can not install the driver while logged in via RDP." Say what? TightVNC has no problem installing winvnc.exe over RDP but UltraVNC says you can't do so. Now, I have no idea why it can't - but the installation went ahead anyway. So now I have no idea if the installation actually worked or not. Both the server and the client come up and run though. So my first question (probably answered in the FAQ I have as of yet to read) is: Why does the installer do this? Should it be doing this? And if not - maybe the developers should look into this.
I also installed UltraVNC onto my main computer. No problems there. But when I try to connect to the server it says "You can't connect until you have a valid password." I had set one on my main computer's installation already but I retype it in and try again. No good. So I try resetting the password on the server and try again. No good. So something must NOT have been installed on the server like the installer said and I am trying to use a program that is broken in some way. Under this kind of a case - I would have thought that the installation program would have simply stopped and uninstalled everything. Not going ahead and installing everything and then presenting a broken program to the user.
So then I go to uninstall the software - which it does nicely!
Only I'm told I have to reboot my system to complete the uninstall. That is not true under TightVNC. You just uninstall and go on down the road.
So three main things:
1. Can't install under RDP (which TightVNC does allow).
2. The installer doesn't stop the install if there is a problem and back out any/all installation information.
3. Upon uninstall a reboot is required.
Using TightVNC I 1)can install it via RDP, 2)Unknown if it would stop the install because the installer doesn't have a problem like the above, and 3)Uninstalling TightVNC just removes everything without requiring a reboot.
Ok - about this time you are probably wondering why I even tried UltraVNC at all. If so - then you have forgotten the first thing I said. Which was I hoped to switch to UltraVNC from TightVNC because UltraVNC has more features and TightVNC's file transfer section does NOT work most of the time. It just crashes TightVNC. So I've set up a file server to transfer files. TightVNC also doesn't have a chat feature (which would be nice when I take over my wife's computer and freak her out). Instead, I have to bring up Notepad to do my chatting. Not that much of an inconvenience, but a built-in chat feature would be nicer. So don't think TightVNC is perfect and I'm blasting UltraVNC.
Oh! One last thing. I was not aware (because I didn't think about it beforehand) that UltraVNC's winvnc.exe would interefere with TightVNC's winvnc.exe. I was wrong. UltraVNC though, should be able to check to see if winvnc.exe is already installed, ask what version it is, and not attempt to re-install it if it is already the same version and/or already installed. Should not both UltraVNC and TightVNC be able to run on the same system? I would think so (as separate processes of course) but maybe not. However, UltraVNC could check to see if port 5900 is already in use and use a different port (or ports) rather than trying to just take over. Or to put that another way - BOTH TightVNC and UltraVNC should be able to play nicely together rather than one trying to usurp the other's port usages.
Ok - blast away!
I have gone back to using TightVNC but I will check here after a couple of days to see what people have to say and to respond. Again, I do really like the way UltraVNC looks but right now, since my computers are all in use 24 hours a day 7 days a week (I am converting our huge VHS tape collection over to WMV files so we can get into the 21st century mode) - I had to have something simple to install and use on all of my different systems. The loader computers (the ones reading the VHS tapes) had to be able to ship the captured video over to my editor systems (to crop blue screens and static) which then send the files to my other editor systems (which brighten/darken the video depending upon how the tapes have degraded and to crop the audio track) which send the files to the final destination computer so we can watch them. A lot of effort for something which we probably could buy for $10.00 - but there are a lot of home movies we can't replace. So I'm just doing them as I get to them whether or not they are home videos.