Re: Some general observations and 3.1 issues.

Brian Godette (
Mon, 23 Feb 1998 17:35:03 -0700

>>True..companies should get rewarded for what they do without people
>>ripping them off. But at the same time, there's a big business for cracks
>>and's something all software developers have to deal with.
> First, there's no "big business" for cracks & hacks. There IS a high
>demand, but no money is made, no businesses are founded. That's kinda the

Ummmm, better qualify that statement by saying "In the US, Canada, and
European contries that honor US copyright." There's major businesses in the
middle east and asia that solely exist around "knock-off" and cracked
copies of software, some of which makes it back to the US. I've personaly
seen "copy-shop" versions of Corel and MS-Office. Remember "the market" is
not JUST the US anymore.

> So that makes it what? Ok? A good thing?
> A neccessary evil. Yes, we all have to deal with it. Sadly, we have to
>expect it.
>>Allow programmers to extend the features of CU-SeeMe and redesign it given
>>the core components. It's really not that hard to provide a SDK that
>>details how to use methods for CU-SeeMe control. Licensing on the other
>>hand can become tricky I imagine.
> Really? And you base that statement on what? An understanding of the
>CU-SeeMe protocol? An understanding of the source code from Cornell? Some
>understanding of the source code from White Pine? Your experiences working
>as a professional engineer and handling code that is at least 3 generations
> I'd be interested to know...

Ummmm, no comment, I'll let you find out with everyone else. :)

>>I believe White Pine has switched serial numbers twice..
>>2.0 -> 2.1 required a different serial number.
>>2.1 -> 3.0 required a different serial number.
> Uhm, so?
> Ya know, White Pine as a whole takes a pretty good beating on this list...
>and for what? Are there specific grievances to air? Like: "I called White


Let's all take a short history lesson on WP versions and what happened
between 2.0 -> 2.1 and 2.1 -> 3.1.024 and 3.1.025.

2.0 -> 2.1
The first problem to crop up was between 2.0 and 2.1 versions, which I
passed off on being only slightly suspicious and potentially due to
incompetence. This of course was the full frame updates that WP 2.1.* and
up send. Client-A sends a full frame to Client-B when Client-B first opens
Client-A's vid. WP decided to send this VIDEO over the AUX (CHAT) data
channel as a client-to-client message (same way Geek works for those that
didn't know), there was ZERO reason for this other than one little
important side-effect... it caused ALL WP 2.0 clients to GPF. This was
right at the time when there was a proliferation of 2.0 serial numbers
floating around the net, and also when WP picked up the Pardigm Matrix
MJPEG codec. Now what could be the reason why WP would send this data over
AUX knowing full well that it caused the older client to crash (you'd
expect they'd do at least SOME regression testing), instead of sending it
as client-to-client video which works on every reflector flavor I know of
(or did at the time, haven't done any testing against MPCS).

2.1 -> 3.1.025
And now there's this problem with 3.1.025. B&W video never sends EndOfFrame
messages causing the B&W vid to never refresh on NON-WP 3.* clients. This
"bug" (I only call it that because there's no real way to prove it was
deliberate) showed up in the very last release of 3.1. 3.1.024 didn't have
this problem, but somehow it just "showed up" in 3.1.025. This absolutely
breaks compatibility with older WP and non-WP clients. (Something is
starting to smell around here)

Then of course there's all the minor annoyances like truncated packets that
are smaller than what the packet header says they should be. And the
inverse where the client sends packets sometimes twice as large as the
internal header says it should be. And of course sending a bunch of small
video packets (300-400 bytes) instead of a "large" packet (1-1.5K), which
not only increases packet overhead but increases the likelyhood of lost

Of course, it's required that I mention that the current version of ERef
fixed the first problem (long ago, before I even made it available) and the
next release fixes the second (along with chat-spoofing and a number of
other apparent WP 3.1 specific problems). This is no easy task as it
requires the REFLECTOR to DECODE all B&W video from 3.1.025 clients and
make the ONE BYTE change to the packet header of video packets that modify
the bottom of the video. Needless to say I'm a bit peeved. But hey, if
you want to play these games with your customers go right ahead, they'll
only find out later and resent you for it.