Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!hao!nbires!isis!udenva!rabtrs!rab
From: rab@rabtrs (Rich Bilancia)
Newsgroups: comp.unix.questions,comp.unix.xenix
Subject: Re: Unix/Xenix on the 386
Message-ID: <150@rabtrs>
Date: Wed, 13-May-87 12:38:49 EDT
Article-I.D.: rabtrs.150
Posted: Wed May 13 12:38:49 1987
Date-Received: Sat, 16-May-87 07:18:39 EDT
References: <146@rabtrs> <865@killer.UUCP>
Organization: CG&S, Littleton, CO
Lines: 57
Xref: mnetor comp.unix.questions:2298 comp.unix.xenix:334

> in article <146@rabtrs>, rab@rabtrs (Rich Bilancia) says:
> > 
> > I also have written an article for the August issue of UNIX/World taking a
> > first look at XENIX System V/386 in both of the above hardware environments.
> >                              ^^^
> > Keep an eye open for it.
> 
> 
> Gee Rich, not that I won't look for and read your article, but how about a 
> hint.  Do we have to wait till August to at least find out if it's any good
> or not?  Just a one liner might do.
> 
> Tony Holden
> ihnp4!killer!tony

OK, here's some of the article

Either UNIX systems really are getting easier to install or I'm just
getting used to the level of difficulty.
But, I really think that it's the former because XENIX 386
is easier to install than any other version of XENIX that I've used.
The default installation is with a single hard disk partition on the
primary hard disk and a reasonable default swap space of 2.5MB.

The system seems very fast while reading diskettes, formatting the hard drive,
booting the system, and screen refreshing in general.
Those impressions were not incorrect as you'll see below.

One of the significant limitations of XENIX on the other Intel
microprocessors is the way that memory is allocated in 64K segments, requiring
the implementation of memory models that are selected by the applications
programmer at compilation time.
The four 80286 memory models are called small, medium, large and huge.
The 80386 microprocessor also allocates its virtual memory in segments, but the
segments in the 386 world are 4 gigabytes large.
This limitation should hardly ever, if ever at all, be a problem for
application developers.
In fact, the elimination of this memory model (if you'll excuse me) nonsense
will likely attract many MC68000 enthusiasts to the roles of XENIX 386
developers.

Of course I had to verify the 
promise of upwards XENIX software portability, so
I chose to check two of my favorite XENIX System V/286 tools:
the Korn Shell from Aspen Technology (Parsipanny, New Jersey) and
the Accell Integrated Development System from Unify Corporation (Sacramento,
California).
True to the XENIX promise of binary code compatibility, both products
performed flawlessly in the XENIX 386 environment.

The only problem that I experienced with XENIX 386 was a bug in the Gamma
Release kernel that was documented and corrected too late for inclusion in the
Gamma Release 3.05.

The one other thing that did surprise me with many of the utilities that are
distributed with XENIX 386 is that they are not recompiled 386 code, but
rather the same executables that are distributed with XENIX System V/286.