HP3000-L Archives

February 1999, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Dirickson Robert S (Steve)" <[log in to unmask]>
Reply To:
Dirickson Robert S (Steve)
Date:
Mon, 15 Feb 1999 18:26:32 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
> Mike writes:
>
> > NT is without a doubt more open than MPE. API's are the primary
foundation
> > for programming interfaces when developing Microsoft products and can be
> > linked to more, "off the shelf" software.
>
> An API is nothing more than a system subroutine. On the HP3000, they're
called
> "intrinsics". Otherwise, the concepts are identical. For more
> information on HP3000 system intrinsics, see:

I'd guess that Mike understands that. His point appears to be that the set
of intrinsics/APIs/system calls/privileged operations/whatever (MME,
anyone?) presented by NT is substantially more complete than that presented
by MPE. And I have to agree with him; the kinds of things that are available
to a very restricted set of people in the MPE world--owners of things like
AIF:OS and AIF:MI--are directly available to anyone with any form of the NT
SDK documentation, including the documentation distributed with
NT-oriented/capable language products like Microsoft's Visual Studio, IBM's
Visual Age, and the Inprise (ugh--does *anyone* like that name?) C++ Builder
product. Likewise, anyone with the interest (OK, so a little skill comes in
handy too) can develop hardware drivers for NT, because the DDK
documentation is readily available.

For example, say I have a listener process that, upon receipt of a valid
client connection, wants to spawn a new process to handle that client, and
the new process needs to "be" the client, not the listener. On MPE, I have
to have the AOF:OS product and documentation so I can code in a call to
AIFCHANGELOGON. On NT, anyone with an NT-aware compiler and the
documentation for CreateProcessAsUser()--available at any bookstore with a
reasonable computer section--can code the capability.

Or consider GLANCE(Plus)/iX. What does it take to duplcate that
functionality? On MPE it takes the AIF:MI product, which ran more than a
couple of shekels last time I checked. On NT, you don't have to "duplicate"
it at all: not only is the documentation for the performance-counter
registry information in the hands of anyone with an NT development
environment, but the source code of the Performance Monitor application that
ships with NT is there too.

Does this greater accessibility mean MPE's inevitable demise? Of course not;
issues like stability and performance still count for something. But the
spec for "bet the company" reliability seems to be quite a bit more elastic
of late than in the past; given a choice between 99+% reliability supported
by a small cadre of gurus or 96% reliability accessible to anyone with a
modicum of skill and some free time (an overstatement, but that's the
perceived difference), more and more companies are willing to choose the
latter. Of course, many of these are the same people who were willing to
consider Access as a viable contender for the role of departmental data
repository, but there are a lot of them.

Steve


Steve Dirickson   WestWin Consulting
(360) 598-6111    [log in to unmask]

ATOM RSS1 RSS2