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