PC/IX and Xenix Reviews

[HFISCHER at USC-ECLB.ARPA]

From:  Herm Fischer <HFISCHER at USC-ECLB.ARPA>

In preparing for Ada environments at my company, I am attempting to
employ distributed Unix systems to offload the ever-increasing demand
for computing resources on our central computers.  There are lots of
PC's and XT's around, but they are mostly used for stand alone work,
with the bulk of our engineering acitivities concentrated on hosts.
These hosts are loading up to alarming proportions, and a way to
offload host jobs would certainly improve response time.  Ada tools
will further increase our demands for these resources.

I have anxiously awaited (since January) for my own copies of PC Unix
to begin to attempt to port tools and tasks from the hosts, and to
determine how well they perform.  (Readers in March remember my
astounding observations of speed for Prolog benchmarks.)

I have now had enough time on two different PC Unix implementations,
IBM's PC/IX, and Santa Cruz's Xenix, to comment on what a PC (XT) is
like with Unix. The PC is no longer a toy!  It's Unix performance is
sufficient, when compared to loaded hosts, to make it's use
worthwhile.  It's ability to integrate, through Unix communications
facilities like UUCP, UUX, and mailers, with networked Unix hosts, is
really superb!  But, don't expect miracles (yet).

If you don't want to read on, I can summarize by saying that both
PC/IX, and Xenix will eventually be outstanding products.  IBM's has
more polish (and fewer bugs) now, and the potential for a really neat
multi-windowed forms-driven slick user interface.  Xenix's is much
more Berkeley-ish, with tools familiar to the most die-hard VI and
c-shell enthusiasts.  Each system is faster than the other at some
things and aggravating at others.  Xenix's support crew definately
wins out on customer responsiveness (sorry, IBM), by a mile, because
"no" and "we will consider it" are not in their vocabulary.  Xenix is,
however, substantially more expensive than IBM, due basically to a
warranty which makes you pay for updates and future releases (free
from IBM for two years).  Furthermore their license agreement is so
restrictive (compared to IBM's) that my next net-note may be from the
county jail.


Unpacking the Boxes and Installing Unix


Both systems come in cartons which seem to weigh as much as a case of
wine.  Both products come with excellent installation instructions,
and lots and lots of floppies.  Xenix takes over an elapsed hour to
install and PC/IX installs in half the time (I've done each several
times).  You are in for a tremendous reading assignment if you do not
know Unix setup and UUCP setup before you open the box.


Manuals


Both products basically word-processed the Bell documentation for
System III Unix.  The differences are that IBM probably could afford
to invest more in adding helpful sentences here and there.  I hate to
say, but you need IBM's documentation in some places and Xenix's
documentation in others, for unless you are a Unix expert, each system
preserves holes in Bell documentation in different areas.

Xenix's typeface is harder to read than IBM's.  But IBM let the
printing out to a printer whose offset ink smudges under sweaty or
greasy fingers.  Nobody is perfect...


UUCP Communications


Bringing up UUCP is usually reserved for a cult of Unix experts who
reserve the right to never divulge how the logon files work.  IBM's
documentation in this area fills in more holes than Xenix's, but it
sure takes lots and lots of (and even more lots of) recursive reading
and patience.

IBM includes autodialer (ACU) code for Hayes, Ventel, and DEC modems,
and it works exactly as described (you just have a heck of a time
becomming a UUCP logon cult member).  I am using a Qubie modem, and
the Hayes code drives it well.  As of last weekend I still did not
succeed with Xenix's UUCP (which only supports Hayes dialers). 

IBM documents how to write your own dialer code (with Rixon as the
example) and the Xenix folks promise to do likewise soon.


KERMIT


Since I have not yet wrung the last setup error out of Xenix UUCP, I
have been using Kermit when using Xenix.  Kermit.c, as distributed,
with the FIONREAD stuff disabled, works right on the first attempt.
However, Kermit.c will not work right under PC/IX.  I spent several
hours converting the Berkeley stty and gtty calls to the newer IOCTLs,
and it still gets hung.  With UUCP under PC/IX, I have been too
satisfied to finish debugging Kermit yet on it.



Is IBM Trying to Announce Unix for the 370???


The connect program (which both systems have), operates similarly to
Kermit, in that once speaking to a remote site, you must enter a
special escape sequence to get back to the local machine.  For PC/IX,
the strange escaping sequence, control VM (actually ^Vu^M) leads me to
think somebody slipped their tongue on a product whose letters start
with VM and end with UNIX. I always loved rumours...


Performance


Either system, even on as small as a 256K properly configured machine,
is better (at simple things) than anybody's medium loaded VAX.

PC/IX has a snappier shell response than Xenix.  Xenix's C code runs
faster than PC/IX's.  Basically, PC/IX is two- to four- fold faster
than Xenix at shell execution (loading things, getting the editor up,
etc.) and editing, for an identical configuration.  (This is without
making any tasks "sticky" in the swap areas.) But once in execution,
the "C" code generated by Xenix is faster.  (For example, the UNSW
Prolog interpreter runs a standard test at 192 logical inferences per
second on Xenix, while only getting 182 per second on PC/IX.)


Limitations


PC/IX has a 64K size restriction on programs.  Xenix doesn't limit
code size (medium model).

PC/IX limits data structures in "C" to 4K bytes.  Xenix doesn't.  But
both limit data segment size to 64K.

The PC/IX restrictions make no sense, especially if one plans to
support Ada compilers and programs.  The silly 4K restriction is also
a problem in porting existing "C" code from PDP/11's and from Xenix
systems.


Porting an Application


I ported a very complex specialized "menu generating editor" program
for a DoD terminal product, from the PDP 11 to PC/IX.  (It ran into a
compiler bug on Xenix.)  (I also ran into a PC/IX compiler bug, but
it was an easy one to work around.)

Since this application only runs on PC/IX, this paragraph only
pertains to PC/IX.  The "C" routines which write on the CRT, in the
printf family, are slower than molasses (140 to 150 characters per
second on the console screen).  I replaced them with routines to do
direct screen memory writes (about ten times faster).  These routines,
"ibmcur" and "ibmprt" will be submitted to the INFO-IBMPC lending
library of public domain software in a separate message.  (These
routines are most interesting, because they show the casual hacker how
to embed assembler code in his "C" programs, and how to access memory
outside of the 64K allocated data segment.)

(Perhaps the slow speed of screen writing is due the the enormous
flexibility the PC/IX console handler has.  An Interactive employee
called the handler a "brain-damaged" ANSI emulation.  I disagree; you
can set colors, erase in fields, selectively scroll, and even run most
vt100 code.  But to do this within the vertical retrace period of the
color display slows writing speed down!)


Editors


PC/IX is Interactive-ish in flavor, with a distant cousin of the Rand
Editor; Xenix supports a version of the VI editor.

PX/IX has a quarterplane style editor, with full keyboard integration,
online help, pop-up menu's, pop-up windows, fill-in forms (structured
files), multiple windows, and more to come. (They tell me at
Interactive that a product soon to be available on the VAX,
"ten-plus", may be distributed by IBM for the PC.  I have seen this
product and eagerly await it.  I saw a developer editing his "C" code,
popping up a menu and selecting compile, and after a pause, seeing the
error messages in pop-up boxes pointing to the respective offending
syntactical construct.  It sure makes Unix more user friendly, even if
the editor now becomes a pseudo shell.  I'd love to have this for
Ada!)

The Xenix VI is honest VI.  A mode-sensitive non-quarterplane editor,
but well loved by many users.  (I am partial to EMACS.  Sorry, Xenix.)

The Xenix VI editor does not work with my (Logitech) mouse; it
presently only uses standard VI commands ("hjkl" for cursor movement).
The PC/IX editor supports the mouse, though it crawls slower on screen
then under my hand.

If you want windows and menus under Xenix, it has v-shell; however,
this program crashed the system several times for me.  V-shell is
basically the same as R.F. Starr's "UTIL" freeware program under
PCDOS.


Impressing Your Friends with Dial-Up Ports


Both Xenix and PC/IX allow you to enable your modems on the
asynchronous ports and have up to two dial-up remote users.  I leave
my system on at night in the office, and call it from a terminal at
home.  Unless your remote users try to do "makes" or otherwise pig-out
the feeble 8088 CPU, response time is not much worse than with a
loaded VAX.  PC/IX even distributes accounting software, with
instructions on how to charge for usage like a big host.

A **MAJOR** PC/IX annoyance is that the editor, with all of its
wonderous user friendliness, is not runnable remotely.  When I go home
and call up my PC with PC/IX, I must grovel and use the yucky ED
editor.  All (with no exception yet found) other PC/IX programs seem
to work properly at remote terminals.  I know that this editor is
written for VAXes and 11's to work with regular remote CRT's.  (The
PC/IX version obviously does direct console screen-writes, and will
not work remotely; even if IBM were to have to charge extra to have
the editor work remotely, it would be worth it.) VI works with all
terminals, local and remote, on Xenix.

I do not recommend planning to have multiple online users doing any
CPU-intensive work;  both systems are really only as fast as the 8088.


Minimal Systems


Both systems run decently on a "properly configured" 256K machine.
But they degrade differently.  PC/IX seems to run at the same speed
(as a large memory configuration), when executing a program or the
editor, and just slow down when loading programs, starting print spool
activity, and the like.  If you let cron do its "sync" every minute
(as distributed) the 256K program will stop while the swapping occurs
(2 seconds or so).  That is disconcerting while editing, but easily
remedied.  Xenix, unless you disable the remote ports, will crawl in
256K.  (15 minutes to do a 1 1/2 minute compile, for example.) With
ports disabled, it's performance is nearly the same as with more
memory; and, when swapping activity occurs, Xenix is more graceful,
becomming sluggish at the VI cursor but not stopping you entirely as
PC/IX does.


Jailtime


The license agreement for Xenix restricts Unix use to a single
machine.  An expensive product, and you cannot even use it at home in
the evening and upstairs at work when your secretary is fancy-fonting
under PC-DOS.  You cannot even loan it to a friend for him to try on
his PC on the weekend.  IBM wording is far more lenient; you can only
use it on one machine at a given time, and they do not even ask you
to specify the serial number.


Conclusion


Unix for the PC is here.  Two honest Bell System III ports have been
reviewed, and both perform surprisingly well.  Idiosyncrasies are
different for each system.  The smaller company is more responsive;
the larger has more user friendly software.  For every strength you
will find a peeve.  Time will straighten things out.  Competition is
wonderful (especially for software products).
-------