Bell Tech 386 SysVr3 (really a put-down of Xenix)

[Greg Woods]

In article <152 at ispi.UUCP> jbayer at ispi.UUCP (id for use with uunet/usenet) writes:
>In article <1988Jul30.141708.3175 at gpu.utcs.toronto.edu>, I write:
>> 
>> [ stuff about buggy kernels, etc. ]
>
>I don't understand what you are referring to.  We have sold, installed, and
>support more Xenix systems than you have.  Over the past year our customers
>have had a grand total of 3 crashes.  All of these crashes were on one computer
>leading us to suspect hardware.  While the kernel may have bugs I have not
>been impacted by them to a large extent.

I didn't say we didn't use it to the max!

>> The Xenix serial driver cannot share interrupt vectors with more than
>> one port.  It will lose data at 1200 baud.
>
>I normally don't tell people that they don't know what they are talking
>about, but you don't.  I have a number of systems which are hard-wired 
>together using the normal TD,SD, GND wires on the RS232 line.  I have used
>uucp, cu, pcomm, a local terminal program, and the ZMODEM protocal running
>at 19200 baud.  The wires are unshielded, about 200 feet long, running in 
>places next to ac power lines. As you know, the RS232 spec. is valid for
>50 feet.  We have had NO DATA LOSS ON THESE LINES IN THE PAST 2 YEARS.  This
	-The spec and real life are different
					-Have you collected stats?
>is using standard com1 and com2 ports.  At times we have boosted the speed to
>38400 baud, and have had very few problems.  It is really nice to watch a 
>5 megabyte file get transferred at these speeds.

Unfortunately I neglected to mention with strong enough voice that the
I/O was through ports sharing an interrupt vector, not individual ports
like COM1.  I don't mind being told I don't know what I'm talking about,
but I do mind when people don't listen (ie read) what I say.  We tested
the AMI-LAMB 8-port board which is supported by the generic serial
driver, so I assume most other boards of similar design will experience
the same problems.  The actual configuration was worst-case -- lots of
data going out the high priority port, and lots coming in the low
priority port.  Literally with a loop-back connector.  The situation
quickly degraded with any other system load.  We even tried XON/XOFF.
Unfortunately, this was before RTS/CTS was fixed.

The Sys V 3.0 release notes list this as a problem with the 3B2 using
more than 2 9600 baud lines, even with (hardware) flow control.

>Regarding the interrupt vectors, you are correct.  However, I would like to
Like I said, read it first. (and maybe again after! :-)
>know if the 386/ix product can share the interrupt vectors.  You don't say.

I don't know, and I won't bother finding out.  With smart I/O it won't
matter.  I hope.  (The Consensys card passed the test BTW.)

>> Interrupt driven ports ALWAYS take a lot of cpu.  Try a really smart
>> board, such as Consensys PowerPorts.
>
>Correct, but this statement is true for ANY unix, not just Xenix.

Ever see an original VAX 11/780 with 64 users typing away at vi?  Not a
pretty sight.  I once though that was fast!

>> >| 1.  SCO may have the "look and feel" of UNIX, but it is not UNIX and is not
[ I thing we're missing the original attribution. ]
>> >	This is just blatently untrue. Xenix is based on AT&T code. It's
[ deleted mess of comments ]
>> Unfortunately, not all of the utilities were taken from that tape (ie. uucp).
>
>Xenix has been available for several years now.  I didn't see any other 
						-that's the problem :-)
>versions of unix until about a year ago.  Microsoft wrote Xenix, then
>licensed it to manufacturers for their own systems (Altos for example),
>and then SCO got a deal to develope the commercial version.  Xenix has been
>a reliable product now for a long time.  It has been ungoing improvement
   ????????
>for a long time.  It has features that the standard unix does not, (I am
			-name one of REAL use, I dare you.
>not going to list them here).  A lot of these features have been included
>to optimize the system for the end-user market.   While some portions of
	-or further confuse
>Xenix are less than excellent (uucp as you mentioned), if you would read the
						- with not even an excuse!
>papers you would know that version 2.3 will be released on August 15.  Among
>other things it will have HDB uucp, and binaries which run on AT&T Unix will
>run on Xenix without recompiling.

I understand that Microsoft just bought the rights.  If you're looking
at Unix for the Intel junk only, you have tunnel vision.  The rest of
the world has been screaming ahead.  Ever hear of the 68000, or NS32000,
or WE32000, or AMD29000, or SPARC, or DEC, Cray, or ........

Why is Xenix, which used to be first, now last?

>> The real problem is that SCO have built up a tremendous support
>> reputation, and they are very wary of making any changes that may have
>> dozens of users calling up.  Take for example the choice to make the
>> user utilities display disk blocks as 512 byte units, even though the
>> 2.x kernel uses 1024 byte blocks.  One support person hinted to me that
>> they did not want to scare people who did a df, and found half their
>> disk was suddenly gone!
>
>Question for all you other unix gurus:  What systems which have the df command
>report in 512 byte units, and what systems report is 1024 byte units?

386/ix uses 512 byte blocks. (inside and out)

>Unix has been developed over the years, and the commands are a conglomeration
>of many different people's ideas of what they wanted from the system.  Because
>of this there is not a lot of sense in the way different utilities report
>the same information.  SCO is doing the right thing in not changing the way
>the standard commands report information.  If they did then many programs
>and shell scripts will not work.  If you must complain about something 
>complain about something worthwhile, not about standards and compatability.

The standard is to report blocks as they are allocated by the system,
not some imaginary figure.  Standard with all but Xenix, that is.

As for breaking things, if you write code that bad, you deserve it.

>> >	This is true, however virtual memory has been added, which is
>> >	the most visible to most users.
>> I'd of thought it was invisible.  Boy, what a can of worms it is too!
>Using the virtual memory I have had programs running on ten different screens
>which needed a total of 6-8 meg of memory.  While the system was a little 
>slow (I only have 2 meg, with 10 meg of swap space) everything worked.

Some people don't read do they? :-)

>> >compile from 386 to Xenix/286, 8086 and DOS. Xenix has a lot of
>> This can be a very valuable selling point, but 386's (with VP/ix or
>> Merge) make it moot.
>How many one and two person shops need or can afford a good sized 386?  On
>the other hand 286 machines are dirt cheap these days.  Xenix is a good

Cost and price are two different things.

>alternative to OS/2, and having the ability to develope on a 386 and then to
>copy a binary to a 286 (I do it all the time) is extremely valuable and is
>not a moot point.

OS/2 isn't an alternative to anything but HELL.  I forgot about the fact
that you still might need some form of utility to convert COFF objects
to Intel objects for the MS linker (it does still come with DOS?), not
to mention a full suite of libraries.  Oh well, one compiler and VP/ix
should do it without too much expense.  That is, if you HAVE to develop
for MS-DOS....

The point I should have made is that now you can run your old DOS stuff
(if you must :-), and Unix stuff, on the same box. (there's also XDOS)

>> >utilities and tools not in SVR3 and vice versa. To imply that the lacks
>> Such as?  From a developer's point of view (and in my opinion), SysVR3
>> has more, newer, better, tools than any other version.
>	While SysVR3 has newer tools, are they really "better"?  For those
>of us using Xenix the tools available are (in my opinion) better.

First hand use is an eye-opener.  I WAS happy hidden in the Xenix world
for quite some time.  (I'm still a BSD'er at heart).

>> >Xenix/386 passes SVID with the exception of one fairly obscure system
>> Is it binary (ie COFF) compatible yet?  Will the 286 version ever be?
>> Will there ever be a "SysVR4 compatible" Xenix 286?  [ I hope not! :-) ]
>	As I mentioned above, version 2.3 will be binary compatible.  I
>don't know about the 286. 

They say it will be.

>> Except when it generates wrong code, or none at all.  I've ported over
>> 20 Mb of source.  Microsoft have MANY problems with "register" and the
>> 286 makes it almost impossible to get pointer expressions correct.
>I've been able to compile (after setting the correct options) almost everything
>that has come over the net, including (dare I say it) spacewars.  It all
>worked.

Well, I couldn't.  (Secret: try '-Dregister=' for some things.)  Some
things still don't work.  Ever hear of a compiler that generates a
binary without a peep, and a system that then thinks that binary (with
the correct magic number, and a valid x-out header) is a shell script?

A lot of problems are with squeezing stuff into a 286 too.

>> >  I admit that I tested V/386, 386/ix and Xenix/386 and bought Xenix. I
>> >did it based on reliability of the products as of 11 months ago, and I
>> >have seen that the later versions of Xenix are still solid.
>> I bought (as have my clients who could), and STRONGLY recommend, 386/ix.
>> I STRONGLY recommend not touching Microsoft development tools with a 10
>> foot pole.
>Funny, Microsoft seems to be doing well selling their compilers and other
>system development tools.

A lot of people aren't in a position to complain, not that it does any good.

If you want to write serious C code, and not worry about the compiler,
you don't stand much chance with Microsoft.

>Jonathan B. Bayer
>Intelligent Software Products, Inc.
>19 Virginia Ave.
>Rockville Centre, NY   11570
>uunet!ispi!jbayer

[ Sorry about the length folks.  Hopefully this is the end of it.  I've
nothing but defensive remarks (ie flames) left anyway :-) ]
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada