Xref: utzoo comp.unix.xenix:2885 comp.unix.microport:1168
Path: utzoo!utgpu!attcan!uunet!jetson!john
From: john@jetson.UUCP (John Owens)
Newsgroups: comp.unix.xenix,comp.unix.microport
Subject: Re: Bell Tech 386 SysVr3
Message-ID: <86@jetson.UUCP>
Date: 3 Aug 88 18:45:05 GMT
References: <25145@ucbvax.BERKELEY.EDU> <465@sp7040.UUCP> <11643@steinmetz.ge.com> <1988Jul30.141708.3175@gpu.utcs.toronto.edu>
Organization: SMART HOUSE Limited Partnership
Lines: 34

In article <1988Jul30.141708.3175@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes:

I was tempted to attempt a point-by-point reply to the flames about
Xenix, but I'll restrict myself to one or two comments.  Many of your
complaints are quite true, however, and I certainly wish that they'd
convert all the block reporting utilities to report file system size
blocks....

First, you are consistently comparing various *386* System V ports
with *286* Xenix.  Comparing with 386 Xenix would be a much better
comparison; Xenix and other Unixes on 286 boxes are quite handicapped
by the segmented architecture.

> The Xenix serial driver cannot share interrupt vectors with more than
> one port.
True.
> It will lose data at 1200 baud.
Not for me.  I've run UUCP connections at 9600 baud on direct serial
lines on Xenix 286.

> 386/ix has trouble with function pointers.  Otherwise I've found it
> better by far than the Xenix 286 compiler.
I hope so - almost any 386 compiler is going to be better than any 286
compiler, since you don't have to worry about segmentation.  I've had
only one minor problem with Microsoft's 386 compiler (an infinite
spill, easily worked around), and am happy with the code it produces.

In general, I'm glad that there are enough choices that everyone can
find a system that they like....

-- 
John Owens		john@jetson.UPMA.MD.US
SMART HOUSE L.P.	uunet!jetson!john		(old uucp)
+1 301 249 6000		john%jetson.uucp@uunet.uu.net	(old internet)