🚀 go-pugleaf

In article <id.2K0W.G37@ferranti.com>, peter@ferranti.com (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 <1992Dec22.011414.21727@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com 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.

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

> ACLs on objects.

Andrew has this, without abandoning the UNIX programming model.

> Quotas.

I've seen both hierarchy and user 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.

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

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

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

> >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: that is (getting back to
the original comment), why would you have to buy "all new software" under
OS/2 but not under NT?
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"