Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!ateng!chip From: chip@ateng.ateng.com (Chip Salzenberg) Newsgroups: comp.unix.microport Subject: Re: future of UNIX and microport Keywords: XENIX uport Message-ID: <1989Mar29.185842.14146@ateng.ateng.com> Date: 29 Mar 89 23:58:41 GMT References: <661@micropen> <743@omen.UUCP> <663@micropen> Organization: A T Engineering, Tampa, FL Lines: 31 I agree with David Carlson that we need to keep *calm* when discussing Xenix vs. SysV. Now, on to the discussion, which is already in progress. According to dave@micropen (David F. Carlson): >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. To clear up a few misconception, let me state that SCO Xenix: Includes terminfo, if you want it; Includes termcap, if you want it; Includes V7-ish curses, using termcap; Includes SysV curses, using terminfo; Uses SysV-conformant termio ioctls for tty control. The arguments about terminfo vs. termcap have *nothing* to do with the version of terminal control offered by the kernel. You could put terminfo on BSD ioctls, and you could put termcap on SysV ioctls (as SCO did). >AT&T sucks for not having a sub-second clock interval. Although XENIX nap() >is anemnic compared to BSD ftime(). Which, of course, means that SysV missed the boat. Except for SysV R3.2, which of course includes nap(). -- Chip Salzenberg or A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."