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

Text File | 1992-12-23 | 5.5 KB | 137 lines

Newsgroups: comp.arch
Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!dbased.nuo.dec.com!ryn.mro4.dec.com!news
From: [e-mail] (Peter Mayne)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Message-ID: <[e-mail]>
Lines: 124
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail]
Organization: Digital Equipment Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 23 Dec 1992 05:07:19 GMT


In article <[e-mail]>, [e-mail] (peter da silva) writes:
>In article <[e-mail]>, [e-mail] (peter da silva) writes:
>> You seem to have a strong opinion about this, so could you explain to me
>> precisely how the UNIX API is lacking, and what specific features of NT
>> would be impossible under a UNIX API.
>
>In article <[e-mail]> [e-mail] writes:
>> Which UNIX API? (Here we go again. :-)
>
>The basic UNIX model of resources as objects in the file name space, the basic
>UNIX system calls, and so on. Clean extensions are, as they have always been,
>encouraged.

But a model isn't an API.
Encouragement of clean extensions is what caused the BSD/SVR4/others problems
in the first place. That's why I asked which UNIX API?

>> Asynchronous I/O.
>> Waiting for multiple synchronisation objects.
>
>I've proposed a general asynchronous *interface* for system calls, that would
>allow both of these. There is no conflict with the UNIX API that would require
>abandoning it.

But you said the UNIX API, not the UNIX API and APIs that you propose. You
asked "precisely how the UNIX API is lacking", not conflicting features.

Your general asynchronous interface sounds interesting. Tell us more in
another thread? (Hey, come on, it's architecture, isn't it?)

>> 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.

>> 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.

>> >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.

Because:
(1) POSIX 1003.1 does not address the many areas that Win32 does.
(2) POSIX 1003.1 is not a UNIX API.
(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).

>> POSIX 1003.1, which is a standard and therefore hardly new?
>
>That's not the native API, nor the one Microsoft is using for primary NT
>software development. And you can't make Windows calls from a program
>running under the POSIX shell.

Assuming you mean the POSIX 1003.1 API, because there is no POSIX 1003.2
shellin NT, neither should you be able to, because then it wouldn't be a
POSIX 1003.1 compliant program.

>(shell, in this case, is apparently Microsoft's term for an emulation
> environment... it's not the command line interpreter)

Microsoft have not implemented a POSIX shell (1003.2), they have
implemented a POSIX API (1003.1). And you can start a program running
under any subsystem (DOS, POSIX, Win16, Win32, OS/2) from the "shell".

>> >Well for UNIX, where access to virtually all system resources is provided
>> >through the filestore, I would agree. But NT has half a dozen different
>> >mechanisms for interacting with the system... how can multiuser security
>> >be managed if it only protects a minor part of the system?
>
>> All interactions with the NT kernel go through the object manager, and hence
>> through the security subsystem.
>
>But is the object manager mapped into a filestore name space? If not, what
>was meant by that original remark, do you think?

Actually, the filestore name space is mapped into the object name space, which
seems to be a much more sensible arrangement to me.

>> >Since OS/2 and NT have virtually the same level of backwards-compatibility
>> >with DOS, how do you make out that the OS/2 approach is any way diferent?
>
>> NT uses the protected subsystem approach made popular by Mach. OS/2 provides
>> a DOS API, but the NT kernel knows nothing about DOS, since DOS (and OS/2, and
>> POSIX, and...) APIs are provided by the subsystems.

>How does this affect the quality of the emulation:

Emulation of what?

>that is (getting back to
>the original comment), why would you have to buy "all new software" under
>OS/2 but not under NT?

Dunno, OS/2 runs DOS/Windows programs as well or better than
DOS/Windows, or so IBM keeps telling us. But I'm not answering that
question, I'm answering yours.

>--
>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