Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!aurora!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Unix vs. OS/2 (was RE: Pournelle on Unix)
Message-ID: <10091@mimsy.UUCP>
Date: 8 Jan 88 02:34:29 GMT
References: <11156@brl-adm.ARPA>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 32

In article <11156@brl-adm.ARPA> GUTHERY%ASC%sdr.slb.com@RELAY.CS.NET
(guthery%asc@sdr.slb.com) writes:
>1) Here are some O/S goodies that stock OS/2 (now playing on my desk)
>has that stock Unix (also playing on my desk) doesn't have:
>	- built-in light weight processes blended compatibly 
>	  with heavy weight processes 
>	- runtime dynamic linking and demand loading
>	- shared global memory segments
>	- file locking by byte region
>	- standard system calls from drivers
>	- periodic signals

SunOS 4.0 (of course it is not *out* yet) has all but two of those.
The two are lightweight processes (hard to do right, as the Mach
group at CMU discovered, because no one agrees as to what is `right')
and system calls from drivers.  The latter is a horrible thing to
do to a kernel (my opinion, but shared by a number of friends).

>	- systemwide semaphores
>	- file write-though
>	- system trace

As for these, I am not sure what is meant.  SunOS 4.0 has SysV
semaphores and mapped files.  If you have 4BSD-based *source* (such
as SunOS 3.x---not having seen 4.0 source I am not sure it is still
there, though I imagine so), there is a system call trace facility,
but it is very primitive.  On the other hand, source level debuggers
can trace system calls from user programs.  (Having kernel source
is usually required because most vendors compile without -DSYSCALLTRACE.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris