NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/arch/11917

Internet Message Format | 1992-12-23 | 5.5 KB

Path: sparky!uunet!olivea!decwrl!deccrl!news.crl.dec.com!news!nntpd.lkg.dec.com!ryn.mro4.dec.com!news
From: [e-mail] (Peter Mayne)
Newsgroups: comp.arch
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Message-ID: <[e-mail]>
Date: 23 Dec 92 21:23:21 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail]
Organization: Digital Equipment Corporation
Lines: 125


In article <[e-mail]>, [e-mail] (peter da silva) writes:

>That's right. The UNIX programming model. The point is that the UNIX API is
>very high level, and can be modified to provide any capability I've ever
>heard of without breaking it. There is NO excuse for any new operating
>system after about 1984 or 85 to use anything lower level. It increases the
>cost of software design, increases the cost of education and training, and
>decreases the amount of commonly available high quality software.

OK, try this. VMS has something called an AST (Asynchronous System Trap) which
is similar to a user-mode interrupt. This may occur at any time: for instance,
an asynchronous I/O can call an AST routine when the I/O completes. When the
AST routine completes, control returns to the code that was executing at the
time the AST occurred. (The analogy in NT is the APC, or Asynchronous
Procedure Call.)

Now, much of the run-time stuff in UNIX is non-reentrant. In particular, the
use of errno springs to mind. If the AST (or APC) was introduced into the
UNIX model, how can I use these non-reentrant routines safely in an AST
routine without screwing things up?

>There is nothing in Windows, Windows NT, or OS/2 that requires a basic
>system interface other than UNIX-style I/O. The only reason for even
>considering anything else for a conventional operating system is simple
>cynical marketing decisions.
>
>> >> ACLs on objects.
>
>> >Andrew has this, without abandoning the UNIX programming model.
>
>> I presume you mean the Andrew file system. But we're talking about operating
>> systems, not file systems.
>
>But the UNIX operating system interface is centered on the file system.

But that doesn't mean that I can put an ACL on a UNIX operating system object.

>> >> Quotas.
>
>> >I've seen both hierarchy and user quotas.
>
>> What are hierarchy quotas?
>
>> BTW, I'm not talking about file system quotas, I mean operating system quotas.
>
>You mean like ulimit?

Get the process's file size limit.
Set the process's file size limit.
Get the maximum possible break value.
NT and VMS people might have a rather more pervasive idea of quotas.
What are hierarchy quotas?

>> >> >Why did Microsoft have to create
>> >> >a completely new API from scratch, and implement it in such a way that
>> >> >programs using it are entirely insulated from their UNIX API environment
>> >> >(POSIX shell)?
>
>> >> Which new API?
>
>> >Win32.
>
>[and Win16, for that matter]
>
>> Because:
>> (1) POSIX 1003.1 does not address the many areas that Win32 does.
>
>Where it doesn't it can be trivially extended to do so.

Including my example above?

>> (2) POSIX 1003.1 is not a UNIX API.
>
>Yes it is.

Why? It is similar to the UNIX API you mention, but it is also
available on non-UNIX operating systems. (NT and VMS, for example.)

>> (3) Win32 is actually based on the Win16 API (and therefore isn't written
>> from scratch), because it makes Win16 programs easier to port, and Microsoft,
>> being a nasty commercial company, recognised that that makes it easier
>> to get new software onto NT (cf porting from Win16 to OS/2).
>
>And the Win16 API is equally broken, with no redeeming features, and no
>excuse for not being UNIX-based.

>Of course Microsoft may simply be putting the 1003.1 support in purely as
>a marketing tool, without any intention of making it in any way useful.
>That would explain it.

:-)

>> Actually, the filestore name space is mapped into the object name space, which
>> seems to be a much more sensible arrangement to me.
>
>So, can I access any arbitrary object that a POSIX program might want to use
>via the filestore name space? If not, that's awfully short-sighted of
>Microsoft, because that's the way UNIX is progressing.

No, because the filestore name space is at the botton of the hierarchy.
Direct object name space access would require access to non-POSIX routines,
and that's a no-no.

UNIX might access everything through the filestore, but not all other operating
systems do. Better? Worse? Different. Especially when you want to change the
format of the filestore. Another example from NT: a file in a file system is
just an object in the object name space. When a file's pathname is given to
the object name parser, the parser will parse the pathname down to the file
system's node, then hand over parsing to the file system's parser. This
would allow a file system with completely different syntax to be inserted
with no trouble. What happens to a filestore oriented operating system
when a completely different file system is used?

>--
>Peter da Silva                                            `-_-'
>Ferranti International Controls Corporation                'U`
>Sugar Land, TX  77487-5012 USA
>[phone]                            "Zure otsoa besarkatu al duzu gaur?"

PJDM
--
Peter Mayne                     | My statements, not Digital's.
Digital Equipment Corporation   |
Canberra, ACT, Australia        | "AXP!": Bill the Cat