future of UNIX and microport

[David F. Carlson]

In article <743 at omen.UUCP>, caf at omen.UUCP (Chuck Forsberg WA7KGX) writes:
> In article <661 at micropen> dave at 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.
> 
> Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 
> Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
>   Omen Technology Inc    "The High Reliability Software"

I am glad Chuck, as the author of a complex program, decided to post.  Maybe
we might even have a flame free, open debate here (for a change!)

Many of the problems he mentions are UUCP, which for a comm program are, 
important.  NULL pointer problems, (I *am* suprised: doesn't Xenix have lint(1)
:-)!), and other 64K compiler stuff will always cause port hassles.

My point was more like my terminfo code, which the Xenix /etc/ttys and termcap
filched from who knows what version, will be a dog to port.  Worse than from
straight BSD that I took much of my low-level stuff from.  Terminfo offers
sanity in that everything is in one place rather than strung out over 159 
different ioctls (which arg does TIOCLBIS take anyway?)  What a mess.

Curses programs using older versions will require substantial mods to run
under SVr3.0 level curses, (which although lacking color is the best curses
I've seen yet.)

As you state, UUCP and any code which requires cooperative file locking will
be a pain.  Any code that requires record locking to maintain consistancy you'd
be nuts to write to an "orphan" UNIX (XENIX).

Writing device drivers (as I often do) in a basterdized  
(SIII+V7+usoft-kruft+SCO-kruft+...) environment must be less than fun.  Getting
good doc for kernel hacking from a "business-oriented" vendor is always fun 
anyway.  (Not that my vendor is stellar in this regard.)

AT&T sucks for not having a sub-second clock interval.  Although XENIX nap()
is anemnic compared to BSD ftime().

Nice debate.  I'll stick with AT&T for the time being (until a nicer POSIX
kernel is standard!)

-- 
David F. Carlson, Micropen, Inc.
micropen!dave at ee.rochester.edu

"The faster I go, the behinder I get." --Lewis Carroll