Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!kth!draken!tut!santra!kampi!hsu
From: hsu@kampi.hut.fi (Heikki Suonsivu)
Newsgroups: comp.unix.microport
Subject: Re: future of UNIX and microport
Keywords: XENIX uport
Message-ID: <20912@santra.UUCP>
Date: 28 Mar 89 23:33:58 GMT
References: <661@micropen> <743@omen.UUCP>
Sender: news@santra.UUCP
Reply-To: hsu@kampi.UUCP (Heikki Suonsivu)
Organization: Helsinki University of Technology, Finland
Lines: 24

In article <743@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>First off I had to get rid off the last few null pointer
>dereferences, these caused core dumps.  That also makes

To my opinion and expreience, null pointers dereferences causing
segmentation fault etc helps a lot to catch some nasty bugs.  True
that lots of software do it nasty way but I helps if one really wants
portability (I also need to port my stuff even down to mesh-dosh).

>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

HDB on all system V r3:s I have used has 10-char+\n locks in
/usr/spool/locks. HDB though isn't too smart about obeying them.
I like /usr/spool/locks style better, though it requires some
work sometimes when installing older software.

>Xenix has the nap call with a resolution of about 20

I saw nap posted in some sources group. It was simple though
requiring kernel relink as it uses a driver which calls kernel routine
which can use better resolution, and had library routine nap which
just opened that devide. I lost that file so I can't tell
what was the call (If someone has it I would like to get it back :-).