Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!tektronix!reed!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Newsgroups: comp.unix.microport
Subject: Re: future of UNIX and microport
Keywords: XENIX uport
Message-ID: <743@omen.UUCP>
Date: 27 Mar 89 00:25:54 GMT
References: <661@micropen>
Reply-To: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Organization: Omen Technology Inc, Portland Oregon
Lines: 68

In article <661@micropen> dave@micropen (David F. Carlson) writes:
:going to r 3.2 soon is a probability.  Why not?  (I'm glad I'm not a XENIX
:developer needing to do a mega-port back to AT&T and I thank Microport for
:being AT&T up to the recent AT&T SV/386 R3.2.)

All this Xenix!=Unix flamage has finally lit my afterburner.

First off, methinks most of the Xenix!=Unix urban legend is
the result of 8086 and 286 limitations.  Unix and 64k segments
are not totally miscible.

As far as Xenix developers "porting back to Unix", I can
relate my experiences porting Xenix Professional-YAM "back to"
Unix, primarily Microport 286 and Interactive's 386/ix.

The first problem is that *nix Pro-YAM no longer fits in small
model, certainly not with the Microport compiler.
Unfortunately, some modules cause an internal error on the
Microport compiler when I attempted to use the large model.
Oh well, the 386 box works OK for duplicating diskettes.

For Interactive's Unix, several changes had to be made.

First off I had to get rid off the last few null pointer
dereferences, these caused core dumps.  That also makes
compiling on SunOS possible.

Then 386/ix uses HDB UUCP, whose locking mechanism differs
slightly from that used by Classic UUCP, BSD UUCP, and SCO's
HDB UUCP.  Which if any of these is the *real Unix* I haven't
the slightest idea.

Another major porting problem is the keyboard handling of fnx
and alt keys.  By default Xenix gives a dozen or so fnx keys,
but there's room in the tables to define all the alt keys and
more fnx codes.  386/ix defaults to a code for each alt key
and some fnx keys and my doco doesn't indicate any way to
define any more.  My keyboard decoder is starting to look like
a Teletype stunt box.

Finally there is this matter of installation.  Xenix
Professional-YAM uses the "install" command that reads a tar
file and then executes a shell script in the /once directory.
386/ix prefers to mount the diskette and then start executing
a program therein.  Of course 386/ix is easier to set up
because there are no 286 users to support.

Another difference related to the timing of short intervals.
Xenix has the nap call with a resolution of about 20
milliseconds.  The closest thing for !Xenix is the poll call,
but there may be more Unix systems out there that support nap
than poll so far.  It's a shame the keyboard and tty lines
aren't "streams devices".

I'd love to use the BSD style select call available in recent
versions of Xenix.  Unfortunately, 386/ix doesn't have that,
and Pro-YAM needs redesign to take advantage of select.  So,
no select.  Maybe it's part of SVr5.

Meanwhile, I have some programs compiled in 1985 still running
on Xenix 386 2.3.3 using a 600 MB "big fat scuzzy Wren V".
Sure is nice not to have netnews blow out the freelist already.

Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
  Omen Technology Inc    "The High Reliability Software"
17505-V NW Sauvie IS RD   Portland OR 97231   503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAF