How specifically does UltraVNC fail to maintain compatibility with
the RFB protocol? From my perspective, it's a VNC server - my users
connect to it using my client (Chicken of the VNC) and they file
compatibility bug reports on my client when issues crop up relating
to UltraVNC. Walks like a duck, quacks like a duck...
Are you referring to some subtle breaking of the RFB protocol or are
you talking about something like file transfer?
Jason Harris
On Feb 2, 2007, at 2:30 PM, James Weatherall wrote:
Steve,
You've both missed the point and are unfortunately mistaken.
It's not a question of "branding", it's a question of protocol
compatibility. The UltraVNC project does not retain compatibility
with
the RFB protocol, which is why it isn't compatible with standard VNC
releases. By contrast, the TightVNC hobby project has been able to
proceed, adding custom features to our core system and using their own
custom protocol elemants while retaining compatiility with the
standard.
As far as "branding" is concerned, please bear in mind that VNC is
developed by RealVNC Ltd. TightVNC and UltraVNC are projects based
on our
codebase, not "brands" of our software.
I hope this clarifies your misunderstanding of the situation. Your
customers will be happier knowing that your products use fully
VNC-compatible software rather than software that breaks compatibility
with the protocol!
Cheers,
Wez @ RealVNC Ltd
On Fri, 2 Feb 2007, Steve Bostedor wrote:
James and everyone else,
I agree that it's not RealVNC 4.x brand compatible but it is VNC
compatible
in the sense that it is using a VNC protocol and works with any
VNC that is
not the RealVNC brand 4.x base. That's like saying that it's not
Microsoft
Windows compatible unless it runs on Windows Vista. :)
UltraVNC and TightVNC are very popular versions of VNC that are
actively
developed and very feature rich thanks to these "hobbiests". They
should
not be ignored simply because they don't use the same code base as
the
RealVNC branded 4.x code base.
I don't mean to be the annoying accuracy cop here but this
distinction needs
to be clear. UltraVNC and RightVNC are RFB compatible VNC servers
that
branch from and improve upon the original 3.x code base while
maintaining
backwards compatibility (unlike the 4.x code base).
Steve Bostedor
Bozteck Solutions
http://www.bozteck.com
------------------------------------------------------------------
Take control of your network with
VNCScan Enterprise Network Manager
Download: http://www.vncscan.com
------------------------------------------------------------------
-----Original Message-----
From: James Weatherall [mailto:[EMAIL PROTECTED]
Sent: Friday, February 02, 2007 1:01 PM
To: 'Steve Bostedor'; [email protected]
Subject: RE: Hitachi-ZYWRLE Encoding Number (was RE: Introduction
of New VNC
codec)
Hi Steve,
As I pointed out in my original response, the problem with them
having
patched against the UltraVNC hobby project is that that's not
VNC-compatible. Better to product patches against something VNC-
compatible,
or, better still, the standard VNC codebase, if you want people to
be able
to use it!
Cheers,
Wez @ RealVNC Ltd.
-----Original Message-----
From: Steve Bostedor [mailto:[EMAIL PROTECTED]
Sent: 02 February 2007 17:29
To: 'James Weatherall'; 'Hitachi Systems & Services, Ltd.';
[email protected]
Subject: RE: Hitachi-ZYWRLE Encoding Number (was RE:
Introduction of New VNC codec)
Why not patch against both? The UltraVNC and TightVNC
flavors are just as
popular as RealVNC. Why limit yourself to just one version of VNC?
Steve Bostedor
Bozteck Solutions
http://www.bozteck.com
------------------------------------------------------------------
Take control of your network with
VNCScan Enterprise Network Manager
Download: http://www.vncscan.com
------------------------------------------------------------------
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of James Weatherall
Sent: Friday, February 02, 2007 7:31 AM
To: 'Hitachi Systems & Services, Ltd.'; [email protected]
Subject: Hitachi-ZYWRLE Encoding Number (was RE: Introduction
of New VNC
codec)
Hi Noriaki-san,
I've had encoding number 17 allocated to Hitachi ZYWRLE - using this
encoding number will ensure compatibility with standard VNC and
VNC-compatible releases. The next release of the VNC codebase will
therefore include an encoding "place-holder":
const int encoding3rdPartyHitachiZYWRLE = 17;
I note that you have a version of the UltraVNC hobby project
patched with
your scheme. Since the UltraVNC project is not
VNC-compatible, you will
need to switch to a VNC-compatible codebase if you want to
provides VNC
viewers & servers with your custom encoding.
You say that I need to make patch for RealVNC server, don't you?
(Sorry to my poor understanding to English...)
Not necessarily - which particular VNC version, or VNC-based
software, you'd
like to patch your encoding against is entirely up to you. I'd
would
recommend either patching against the standard VNC release, or a
VNC-compatible project such as TightVNC.
Regards,
--
Dr James Weatherall
Chief Engineering Officer - http://www.realvnc.com - RealVNC Ltd
_______________________________________________
VNC-List mailing list
[email protected]
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
--
Dr. James "Wez" Weatherall
--
Chief Engineering Officer
RealVNC Ltd. - The home of VNC - http://www.realvnc.com
_______________________________________________
VNC-List mailing list
[email protected]
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
_______________________________________________
VNC-List mailing list
[email protected]
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
