🚀 go-pugleaf

In article <1992Dec23.050719.4047@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
> But a model isn't an API.

Before the phrase "application program interface" became chic, the most
commonly used phrase for it was "programming model".

> Encouragement of clean extensions is what caused the BSD/SVR4/others problems
> in the first place. That's why I asked which UNIX API?

If you want to be literal, the comon subset of BSD and System V... basically
Version 7 with a few extensions (the socket interface is pretty universal).

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

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.

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.

> Your general asynchronous interface sounds interesting. Tell us more in
> another thread?

I need to write up a FAQ on it, OK.

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

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

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

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

Yes it is.

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

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

So what? It's a non-1003.1 compliant program. You're saying that the
operating system vendor should make it impossible for a program using the
1003.1 interface to use any non 1003.1 calls? That's insane.

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.

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

What I have read on NT has implied that Microsoft is using the terms "shell"
and "subsystem" interchangably. If that's not the case, s/shell/subsystem/g.

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

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.

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.

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

DOS. The original message I was responding to said that Windows had better

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

No, you're answering a different but related question.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"