From: pjdm@chmeee.enet.dec.com (Peter Mayne)
Subject: Re: NT Subsystems...
Reply-To: Peter.Mayne@cao.mts.dec.com
Organization: Digital Equipment Corporation
Date: Thu, 28 Jan 1993 04:46:05 GMT


In article <1993Jan26.211925.8015@mkseast.uucp>, dale@mkseast.uucp (Dale Gass) writes:
>I can see the elegance in having every user process be a client of a
>subsystem, which is implemented in terms of NT kernel level calls.
>However, these NT kernel level calls are apparently not accessible
>from user level applications, only from the subsystems.  If the subsystem
>decides to provide an API to grant access to the functionality provided
>by the kernel level API's, fine.  If it doesn't, there's no way you can
>achieve that functionality within the subsystem.

That's the idea.

>This strikes me as a serious disadvantage to this design approach.
>I am at the mercy of Microsoft's subsystem implementations in determining
>the functionality I can get out of NT.  They don't provide any full-screen
>control from the Posix subsystem, so all my Posix applications are doomed
>to be pathetic interactively...  This wouldn't be so bad if there were some
>way for the developer to work around it, but there doesn't appear to be
>any way to do so, short of re-implementing the subsystem from scratch.

If POSIX doesn't specify full-screen control (or any other feature that you
want), then MS are wasting time and money by (a) deciding what to add in, and
(b) adding it in. If they do put it in, or you work around it, then it isn't
POSIX.

>Also, I have seen no evidence of a "Subsystem Developers Toolkit", which
>would allow me to write my own subsystem to meet my all of my needs.
>I guess these kernel level calls are the undocumented ones which Microsoft
>doesn't document, because they are "subject to change"...
>
>What I would *love* to see would be either the availability of subsystem
>source code (not likely) so a developer could extend it (which would
>require all my customers to have the new subsystem, ugh!), or even better,
>add some hook for developers to *extend* the API's available from a
>subsystem.

It was exactly the availability of these "features" that caused UNIX to
become the dog's breakfast of various API's that it became. Please don't
let NT go the same way.

>With the latter approach, for example, I could implement a full curses
>by adding the appropriate API's, written in terms of the kernel level
>API's.  This "subsystem extension" (most likely a DLL) could allow adding
>any functionality to any subsystem, in whatever manner is most appropriate
>to the developer.

It is certain that this wouldn't work, since the kernel has no
knowledge of the POSIX environment. The only thing that knows the POSIX
environment and defines the POSIX semantics is the POSIX subsystem, not
the kernel.

>Without many of the common extensions found on Posix compliant system
>(such as curses, terminfo, etc.), the Posix subsystem is more or less 
>useless.  It may meet the U.S. government FIPS, but no applications of any 
>complexity could be made to work under it, so it will not be a Posix system 
>of choice.

Any POSIX compliant program, no matter how complex, should work in the
POSIX subsystem. If FIPS only allows mickey mouse (tm) programs, it's hardly
Microsoft's fault.

If POSIX isn't "complex" enough for you, use Win32. Besides, I don't
really think that people are going to buy NT as a POSIX system of
choice, are they? :-)

>I don't necessarily expect Microsoft to provide these extensions
>themselves, but I do expect them to make it possible for me to provide them, 
>if I wish.  Currently, they don't.

See above. I expect them to make it impossible to provide such
extensions. And I hope it stays that way.

>-dale
>-- 
> Dale Gass, Mortice Kern Systems, Atlantic Canada Branch
>Business: dale@east.mks.com, Pleasure: dale@mkseast.uucp

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

Newsgroups: comp.os.ms-windows.programmer.win32