Path: utzoo!attcan!uunet!sco!kurth
From: kurth@sco.COM (Kurt Hutchison)
Newsgroups: comp.sys.atari.st
Subject: Re: Another great quote from Mr. Good
Message-ID: <1060@scolex>
Date: 16 Aug 88 23:11:25 GMT
References: <3308@druhi.ATT.COM> <1104@atari.UUCP> <364@bdt.UUCP> <1045@scolex> <2474@sugar.uu.net>
Distribution: comp
Organization: The Santa Cruz Operation, Inc.
Lines: 83

In article <2474@sugar.uu.net>, peter@sugar.uu.net (Peter da Silva) writes:
> In article <1045@scolex>, kurth@sco.COM (Kurt Hutchison) writes:
> > I for one agree with the argument that releasing a new OS that breaks
> > old software is a bad idea.  Theological arguments about the proper
> > behavior of programs always take a back seat to compatibility concerns.
> 
> And this is why operating systems have a limited life. Eventually the bugs
> left in to keep the old software from breaking accumulate to the point where
> it's not worth keeping the old software. This is one of the reasons UNIX has
> so far been so successful as a third party O/S: with no binary standard there's
> been no old software to keep running.
While a boon in the developement stage it is a hindrace at the marketing
level.

It is not true of SCO Xenix, we support every binary ever made for any SCO
XENIX.  Our 386 OS will run 8086, 286 and 386 binaries unchanged.
This has turned out to be a good thing for us.  Our binary formats
encode which CPU and OS version they were compiled for.  The same
strategy works for whether it is a Xenix III or V Binary or a Unix Sys V binary,
or COFF format (all of which we support).

In spite of this, Xenix has evolved and changed.  There are lots of
new calls and some old ones (still supported) that are officially obsolete.

> 
> Now that Xenix and COFF have become binary standards, I expect this to change.
> In fact, it's beginning to... look how big the new SV/Xenix/BSD merge is
> going to be. Look how big SV already is.

Lets hope that memory keeps getting cheaper :-).  Our users have confirmed
many times that they want backwards compatibility, memory is never
an issue.  Keep in mind that we sell primarily to businesses who
have a little more money than the Atari end user.  Atari wants
the business users though so these examples are potentially valid.

> But when *IBM* came out with a better (and slightly non-standard) PC it sold
> just fine, despite the fact that ill-behaved programs didn't run on it. They've
> done it twice now, first with the AT and now with the PS/2 line.

This is a good point worth discussing.  When the non-standard
PC's came out they instantly became a standard.  Dos was modified so
that it knew which hardware it was running on and the apps followed
suit.  "Three times" means about once every three years.  Atari's
OS releases are far enough apart that I will concede that it would
be reasonable for them to consider fundamental changes to their OS.
If they released updates every six months they would not want to do this.
> 
> > Ill-behaved
> > programs are the rule rather than the exception, most programs that perform
> > really well were Ill-Behaved.
> 
> This is because the operating system didn't support things, like fast text,
> that the programs needed. I thought one of the reasons for going with GEM
> was to keep stuff like this from happening.

As long as the hardware/OS combination *allows* bad behavior, there will
*be* bad behavior (in my opinion).  A better memory management unit, a
protected mode where I/O instructions are illegal and hardware in general
is not accessible except through the OS might go a long way
to prevent ill-behaved programs.  The Atari ST, the Mega (I think), the mac,
do not have these features.  The Lisa and the Amiga (I think), and the 286
and 386 PC families do.  They all cost more that the ST.

You mentioned the idea of having two mallocs, keep the old one and
add a new one that works.  I really like this idea.  There is lots
of precedent for this kind of approach.  It concedes compatibility
while allowing new programs to take advantage of the new features.
This path does result in (potentially) unlimited growth.
I don't know how much space is left in the ROM's and if the
ST motherboard can handle the newer larger ROM's.

> How did you people get the bourne shell working right on the '86?

I don't know.  It's probably proprietary anyway.  I have probably
said too much in this article already.  Nothing that our marketing
people won't tell prospective customers though.

			- kurt
-- 
-------------------------------------------------------------------------
Kurt Hutchison		The Santa Cruz Operation	Software Engineer
Trumpet player, synth player, pianist, cyclist, philosopher at large
The above opinions (if any) are my own