Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!lll-winken!uunet!tektronix!percival!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: <744@omen.UUCP>
Date: 29 Mar 89 23:53:41 GMT
References: <661@micropen> <743@omen.UUCP> <663@micropen>
Reply-To: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Organization: Omen Technology Inc, Portland Oregon
Lines: 67

In article <663@micropen> dave@micropen (David F. Carlson) writes:
: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)
	Dereferencing of null pointers is a dynamic problem.
		(e.g., if(*s) should be (if s && *s))
	If you have a lint that catches that, send me a copy!

        Come to think of it, it would be nice to see some
        functionality (more sensitive checking) improvements
        in lint since V7, instead of changes to the user
        interface that break other programs.

::-)!), 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
	Terminfo does uses neither /etc/termcap or /etc/ttys
: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.
	TIOCLBIS is part of BSD, and does not appear in either
	Xenix or Unix/386 3.2.
:
: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.)
	That was true of Xenix also, alas.
:
: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
	Talk to the poor lhackers (as in "lusers") trying to
	get Unix rz/sz to work properly under AIX...
:good doc for kernel hacking from a "business-oriented" vendor is always fun 
:anyway.  (Not that my vendor is stellar in this regard.)

	Funny you should mention.  My Bell Technologies "Blit"
	package won't install on Unix/386 3.2, there is a
	FLAG DAY.  When I installed the files manually I
	discovered that the format for driver modules had
	changed completely.  Since the change from Unix/386
	3.0 to 3.2 has in less than a year rendered my high
	resolution X windows system usless, I can't imagine
	how the change from Xenix could be worse.  BTW, my
	Kimtron 4-port board doesn't work with Unix/386 3.2.
:
:AT&T sucks for not having a sub-second clock interval.  Although XENIX nap()
:is anemnic compared to BSD ftime().
	Xenix has ftime(), but ftime is not a substitute for nap()
	if you want to give up the CPU for a subsecond interval.
	Xenix also has select() which I haven't used because it
	isn't in Unix (yet).
:
:Nice debate.  I'll stick with AT&T for the time being (until a nicer POSIX
:kernel is standard!)
        Hmmm...  a nicer Posix standard...  great idea.  For
        openers, How about a dial-out program being able to
        check carrier detect (on the dial-out line, not the
	controlling terminal) efficiently?

"Keep those cards and letters coming."

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