🚀 go-pugleaf

In the newsgroup comp.sys.next.advocacy <1992Dec31.234458.6859@fnbc.com> you wri
te:
>Will OO languages shipped for NT be able to base objects on NT objects, or
>will objects in a running app exist in a whole different name space?  I

NT objects are all kernel objects, so they are generally not used
by user-level processes (which generally don't need -- and for safety
and security should not have -- the ability to define kernel objects)
The NT object manager can be extended to handle more object types
(although there are many limitations to this), but it is not expected
that this is the way developers get OO support. Even subsystems (i.e.
Win32, Win16, OS/2, POSIX) do not define new NT kernel objects since
they are user-level code (similar to Mach 3.0's architecture, but
not NeXT's, which uses a variation of an earlier Mach). NT objects
are very low overhead (hey, they're in the kernel!), and in many
ways are thus also low functionality (they do not, for example,
transparently distribute across networks).

In some sense, microkernel architectures are not the way to TRULY
support objects from "top to bottom". In fact, virtually all of
today's chip architectures don't support objects efficiently. Any
object system running on a modern kernel of traditional design
such as Mach, NT, OS/2, etc. is generally layered on top of
traditional kernel services which are in turn on top of traditional
chip architectures. There exist research object-oriented systems
(like Choices) that are "ground-up" OO, and a number of failed
chip architectures that support OO better. Many IBM chip
architectures are better at supporting objects than others;
these are not found in workstations or personal computers.

Microsoft defined a basic object model and released it in a
set of interfaces called "Object Linking and Embedding" (OLE).
This object model is primative and only contains the minimal
definition required to enable linking and embedding functionality.
The next version (widely available in beta) also includes
storage and external programmability functionality. A future
systems product will extend this model for transparent 
distribution and "plug and play" protocols, and base the entire
suite of OS services on this model.

A point of fact that is lost on many people is that OLE is
the object model that has the widest use today by applications.
It is neither a class library nor a language-dependent model
(although there are class libraries that "make it easier"
shipped by various other parties). And, I'll admit, it has
an ugly API and no interesting tools. But we're working on it ;-\

--
Edward Jung, Software Architect     edwardj@microsoft.com
Advanced Systems, Microsoft Corp.