I think James posted once that he was working on his thesis and wouldn't have a whole lot of time for VNC until he's done...
-----Original Message----- From: Michael Milette [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 12, 2002 12:05 AM To: [EMAIL PROTECTED] Subject: Re: TightVNC 1.2.2, is it beneficial? At 10:06 AM 2002-02-08, you wrote: > >From: "Moreland, Julius" <[EMAIL PROTECTED]> > >Date: Fri Feb 8 2002 10:06am > >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > >Subj: TightVNC 1.2.2, is it beneficial? > > > >I am considering deploying this to our clients in place of VNCr9. > > > >Does anyone have an opinion on this version of Tight VNC? > > > >Any raves or rants? The greatest advantage of TightVNC over WinVNC I have found is that the bug which eats up all your system resources on a Win9x machine and potentially crashing the machine is fixed as of TightVNC 1.2.2. I use VNC to provide remote support and it just wasn't accomplishing the desired effect when the initial connection over a modem would crash the computer of the person I was supposed to be helping. An important fact for me is that unlike WinVNC, I see TightVNC actively being developed which means that there is a better chance of a bug getting fixed sooner with TightVNC than with WinVNC. At least one of the WinVNC developers used to lurk and occasionally comment in the vnc-list but I haven't seen any messages from him in quite a while (are you still around James?). On the other hand, maybe he is hard at work on the next release. Who knows... There are also many other great TightVNC features not available in WinVNC such as logging, user authentication (prompting the user to accept the connection), better data compression, local mouse and cursor and more. When running the server, just click on the Advanced button to see all of the sever enhancements. For the client, just click the "Options" button of the Connection Details dialogue. By the way, there is nothing preventing you from installing WinVNC and TightVNC on the same machine. I don't recommend running them both at the same time although you can run the server from one and the client of the other. However to get the full benefit of TightVNC you should of course be running TightVNC on both the server and the client. It would be nice if the author of TightVNC would add data encryption to the package. I suspect that this might (hopefully) be added in a future release. Now for the downside of TightVNC. I have occasionally found that screen refreshes take a longer to happen with TightVNC than WinVNC. When it happens, it almost seems like the TightVNC client gets very busy doing something because I don't see any data coming across. Finally the screen update happens all of a sudden, out of the blue, usually just as I am about to close the connection. This happens most often when connecting to a WinVNC host. Unfortunately I can not reproduce the problem on demand and certainly not when I am trying to demonstrate the problem. Just about as often, try as I may, I get into a situation where I am unable to convince the TightVNC client that the client and host screens are different, even if I click the Request Screen Refresh option. Disconnecting and reconnecting again seems to fix the problem. I haven't complained about it yet because I can't seem to reproduce the problem with any degree of reliability whatsoever. Being a programmer myself, I know that it is extremely difficult and most of the time impossible to fix a problem if you can't reproduce it. I can say that it appears to happen mostly when the connection is over a wireless network where the speed of the connection fluctuates and may occasionally disconnect briefly (I have no idea though if that fact is related). However this is by no means the only situation in which it happens. As far as reliability is concerned, both TightVNC and WinVNC have served me well for a long time but these days I tend to rely more on TightVNC for my remote screen takeover needs. About the only tip that I can offer is that you try to avoid a mixed WinVNC/TightVNC environment. Most of the reliability issues I have come across occurred when connecting to a WinVNC host server. If you have to run mixed, I would recommend TightVNC hosts across the board as it appears to be more stable, reliable and leaks less system resources on Win9x/ME machines regardless of which client, WinVNC or TightVNC, you use. Constantin appears to have done a great job ironing out a lot of the server bugs since the release R9 of WinVNC. Hope this helps. Michael Milette --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
