On micro kernels and OS alternatives

NTFSD
1

The characterization of microkernels as having a “poor reputation” due
to performance is scurrilous - I’d like to see the empirical data to
back up that accusation.

One of the most capable systems on which I’ve ever had the privilege to
work was a true micro-kernel, message passing OS - even the file system
ran in user mode. It had features that even now would be a struggle on
Windows (15 years ago we saw heterogenous process migration, which we
thought was interesting at the time but since we’d had process migration
for quite a while at that point - you know, where processes move from
computer to computer - we didn’t think it was that spectacular).

The list of micro-kernel OS systems is legion. That would include
Amoeba (someone was trashing it a few weeks ago in NTDEV for some
reason, no doubt because the didn’t like Tannenbaum’s quirky coding
style or something equally important), Accent (that was the microkernel
squished together with UNIX to become Mach), Chorus, V, etc. OSF/1 was
based upon Mach - both the monolithic version and eventually the
micro-kernel version. Performance was not the thing developers or users
seemed to complain about.

Of course performance is highly subjective; even today the Windows
system on which I operate seems to me to have horrible performance
characteristics (why, for example, does IE hang when Outlook cannot
contact my Exchange server?) in comparison to how V functioned for me
15+ years ago on hardware that was nowhere near as capable as what we
have today (Sun 2 workstations anyone?)

Conceptually, microkernel systems solve certain classes of problems
(e.g., distributed systems) extremely well. Of course, just like in the
real world, specific implementations can vary dramatically in terms of
actual performance.

IBM has had multiple micro-kernel based OS projects and as far as I know
they’ve shipped such products. I’m not sure how much influence OSF/1
had on AIX, but given that AIX 5 has the Open Group’s blessing there
must be some…

Windows incorporates numerous OS concepts that were bubbling in the
1980s - message passing, clear encapsulation layers (particularly from
hardware,) platform independence, etc. The concept of journaling file
systems also came out of that same time period (e.g., Cedar) and brought
us NTFS (which wasn’t the first journaling file system but is certainly
the most successful in the Windows arena).

There are a number of ideas from that era that sadly have not survived
so well, such as distributed OS support and distributed file systems.
More is the pity.

Of course, much of what drives the Windows platform success has to do
with its broad base of applications, largely driven by the availability
of powerful inexpensive hardware. The OS, or its structure, has
surprisingly little to do with why the general public buys Windows.

So maybe this boils down to a “GM versus Shelby” argument. Each has
their place in the world (I’ve got space in my garage for the Shelby you
don’t want, by the way…) Of course, for engineers, we often enjoy
working with Shelby but make our living working with GM…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

2

Scurrilous or not, that’s the reputation. I just did a Google search on
“microkernel performance,” and the first 5-6 hits I eyeballed speak of
reputation/perception. Some argue with that, but it is what they address.

To me, “micro-kernel” means encapsulation or isolation of a true OS (speaks
to the hardware). I don’t see the connection between that and capability at,
say, distributed systems.

I’m not aware of any micro-kernel OS that IBM shipped, none at least that
had any longevity and wide use.

–
James Antognini
Windows DDK and WDK Support

This posting is provided “AS IS” with no warranties, and confers no rights.

“Tony Mason” wrote in message news:xxxxx@ntfsd…
The characterization of microkernels as having a “poor reputation” due
to performance is scurrilous - I’d like to see the empirical data to
back up that accusation.

One of the most capable systems on which I’ve ever had the privilege to
work was a true micro-kernel, message passing OS - even the file system
ran in user mode. It had features that even now would be a struggle on
Windows (15 years ago we saw heterogenous process migration, which we
thought was interesting at the time but since we’d had process migration
for quite a while at that point - you know, where processes move from
computer to computer - we didn’t think it was that spectacular).

The list of micro-kernel OS systems is legion. That would include
Amoeba (someone was trashing it a few weeks ago in NTDEV for some
reason, no doubt because the didn’t like Tannenbaum’s quirky coding
style or something equally important), Accent (that was the microkernel
squished together with UNIX to become Mach), Chorus, V, etc. OSF/1 was
based upon Mach - both the monolithic version and eventually the
micro-kernel version. Performance was not the thing developers or users
seemed to complain about.

Of course performance is highly subjective; even today the Windows
system on which I operate seems to me to have horrible performance
characteristics (why, for example, does IE hang when Outlook cannot
contact my Exchange server?) in comparison to how V functioned for me
15+ years ago on hardware that was nowhere near as capable as what we
have today (Sun 2 workstations anyone?)

Conceptually, microkernel systems solve certain classes of problems
(e.g., distributed systems) extremely well. Of course, just like in the
real world, specific implementations can vary dramatically in terms of
actual performance.

IBM has had multiple micro-kernel based OS projects and as far as I know
they’ve shipped such products. I’m not sure how much influence OSF/1
had on AIX, but given that AIX 5 has the Open Group’s blessing there
must be some…

Windows incorporates numerous OS concepts that were bubbling in the
1980s - message passing, clear encapsulation layers (particularly from
hardware,) platform independence, etc. The concept of journaling file
systems also came out of that same time period (e.g., Cedar) and brought
us NTFS (which wasn’t the first journaling file system but is certainly
the most successful in the Windows arena).

There are a number of ideas from that era that sadly have not survived
so well, such as distributed OS support and distributed file systems.
More is the pity.

Of course, much of what drives the Windows platform success has to do
with its broad base of applications, largely driven by the availability
of powerful inexpensive hardware. The OS, or its structure, has
surprisingly little to do with why the general public buys Windows.

So maybe this boils down to a “GM versus Shelby” argument. Each has
their place in the world (I’ve got space in my garage for the Shelby you
don’t want, by the way…) Of course, for engineers, we often enjoy
working with Shelby but make our living working with GM…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

3

There are three instances when direction(s) took different paths -

  1. OS/2 ( I know this because I was around there )
  2. NT. More people know about ( as secondary knowledge ) than we could
    imagine.
    3)NEXT. It was well published in some circle.

In all cases ( if I could recall ) the departure was for performance and
that too becuase of Integrated windowing. X was not all that integrated,
so there is a possiblity that micro-krnl based UNIX OS have been shipped.

THOT was one other msg-based os, that was very popular for WANG and other
small OS shops doing office documentation infrastructures, but I dont
recall any micro-kernel idea there.

-pro

The characterization of microkernels as having a “poor reputation” due
to performance is scurrilous - I’d like to see the empirical data to
back up that accusation.

One of the most capable systems on which I’ve ever had the privilege to
work was a true micro-kernel, message passing OS - even the file system
ran in user mode. It had features that even now would be a struggle on
Windows (15 years ago we saw heterogenous process migration, which we
thought was interesting at the time but since we’d had process migration
for quite a while at that point - you know, where processes move from
computer to computer - we didn’t think it was that spectacular).

The list of micro-kernel OS systems is legion. That would include
Amoeba (someone was trashing it a few weeks ago in NTDEV for some
reason, no doubt because the didn’t like Tannenbaum’s quirky coding
style or something equally important), Accent (that was the microkernel
squished together with UNIX to become Mach), Chorus, V, etc. OSF/1 was
based upon Mach - both the monolithic version and eventually the
micro-kernel version. Performance was not the thing developers or users
seemed to complain about.

Of course performance is highly subjective; even today the Windows
system on which I operate seems to me to have horrible performance
characteristics (why, for example, does IE hang when Outlook cannot
contact my Exchange server?) in comparison to how V functioned for me
15+ years ago on hardware that was nowhere near as capable as what we
have today (Sun 2 workstations anyone?)

Conceptually, microkernel systems solve certain classes of problems
(e.g., distributed systems) extremely well. Of course, just like in the
real world, specific implementations can vary dramatically in terms of
actual performance.

IBM has had multiple micro-kernel based OS projects and as far as I know
they’ve shipped such products. I’m not sure how much influence OSF/1
had on AIX, but given that AIX 5 has the Open Group’s blessing there
must be some…

Windows incorporates numerous OS concepts that were bubbling in the
1980s - message passing, clear encapsulation layers (particularly from
hardware,) platform independence, etc. The concept of journaling file
systems also came out of that same time period (e.g., Cedar) and brought
us NTFS (which wasn’t the first journaling file system but is certainly
the most successful in the Windows arena).

There are a number of ideas from that era that sadly have not survived
so well, such as distributed OS support and distributed file systems.
More is the pity.

Of course, much of what drives the Windows platform success has to do
with its broad base of applications, largely driven by the availability
of powerful inexpensive hardware. The OS, or its structure, has
surprisingly little to do with why the general public buys Windows.

So maybe this boils down to a “GM versus Shelby” argument. Each has
their place in the world (I’ve got space in my garage for the Shelby you
don’t want, by the way…) Of course, for engineers, we often enjoy
working with Shelby but make our living working with GM…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

And those articles do seem to support my contention. For example, from
one of the articles I grabbed on the first page:

“Mach’s performance is a result of design and implementation not the
(\mu)-kernel concept!”

And a nicely put definition:

Micro-kernel Design Principles

Minimality:
If it doesn’t have to be in the kernel, it shouldn’t be in the
kernel
Appropriate abstractions
which can be made fast
and allow efficient implementation of services
Well written:
It pays to shave a few cycles off
TLB refill handler or the IPC path
Unportable:
must be targeted to specific hardware

$.$
no problem if it’s small, and higher layers are portable
$.$
Example: Liedtke reports significant rewrite of memory
management when porting from 486 to Pentium
==>
``abstract hardware layer’’ is too costly

I didn’t make this up - this is right out of some slides of an academic
class - right there on the first page of the Google search you
suggested. *MY* reading of these characteristics sounds like a very
good fit for the design goals of the components in Windows.

Again, a little searching told me that OS/2 contained a microkernel (I
found articles about IBM licensing it to third parties). Workplace OS
was a bit of a disaster, but from what I could tell that’s more related
to the way that IBM works than the underlying technology.

Well, I’d thought of talking about the nicely architected isolation
layer in Windows as being a feature. You seem to view that microkernel
influence as some sort of horrid past that needs to be hidden.

From that, it seems you have a prejudice against a particular
architecture; that’s fine and it certainly beats the C/C++ debate that
seems to war on here every so often. But your prejudice doesn’t agree
with my hands-on experience. My observation intended to be anything
other than a complement for the architecture of the Windows OS. I think
the OS is actually very well architected and works amazingly well in the
face of user mode components that seem hell-bent on taking an excellent
OS base and turning it into Windows 3.0.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Antognini
[MSFT]
Sent: Friday, August 19, 2005 7:41 PM
To: ntfsd redirect
Subject: Re:[ntfsd] On micro kernels and OS alternatives

Scurrilous or not, that’s the reputation. I just did a Google search on
“microkernel performance,” and the first 5-6 hits I eyeballed speak of
reputation/perception. Some argue with that, but it is what they
address.

To me, “micro-kernel” means encapsulation or isolation of a true OS
(speaks
to the hardware). I don’t see the connection between that and capability
at,
say, distributed systems.

I’m not aware of any micro-kernel OS that IBM shipped, none at least
that
had any longevity and wide use.

–
James Antognini
Windows DDK and WDK Support

This posting is provided “AS IS” with no warranties, and confers no
rights.

“Tony Mason” wrote in message news:xxxxx@ntfsd…
The characterization of microkernels as having a “poor reputation” due
to performance is scurrilous - I’d like to see the empirical data to
back up that accusation.

One of the most capable systems on which I’ve ever had the privilege to
work was a true micro-kernel, message passing OS - even the file system
ran in user mode. It had features that even now would be a struggle on
Windows (15 years ago we saw heterogenous process migration, which we
thought was interesting at the time but since we’d had process migration
for quite a while at that point - you know, where processes move from
computer to computer - we didn’t think it was that spectacular).

The list of micro-kernel OS systems is legion. That would include
Amoeba (someone was trashing it a few weeks ago in NTDEV for some
reason, no doubt because the didn’t like Tannenbaum’s quirky coding
style or something equally important), Accent (that was the microkernel
squished together with UNIX to become Mach), Chorus, V, etc. OSF/1 was
based upon Mach - both the monolithic version and eventually the
micro-kernel version. Performance was not the thing developers or users
seemed to complain about.

Of course performance is highly subjective; even today the Windows
system on which I operate seems to me to have horrible performance
characteristics (why, for example, does IE hang when Outlook cannot
contact my Exchange server?) in comparison to how V functioned for me
15+ years ago on hardware that was nowhere near as capable as what we
have today (Sun 2 workstations anyone?)

Conceptually, microkernel systems solve certain classes of problems
(e.g., distributed systems) extremely well. Of course, just like in the
real world, specific implementations can vary dramatically in terms of
actual performance.

IBM has had multiple micro-kernel based OS projects and as far as I know
they’ve shipped such products. I’m not sure how much influence OSF/1
had on AIX, but given that AIX 5 has the Open Group’s blessing there
must be some…

Windows incorporates numerous OS concepts that were bubbling in the
1980s - message passing, clear encapsulation layers (particularly from
hardware,) platform independence, etc. The concept of journaling file
systems also came out of that same time period (e.g., Cedar) and brought
us NTFS (which wasn’t the first journaling file system but is certainly
the most successful in the Windows arena).

There are a number of ideas from that era that sadly have not survived
so well, such as distributed OS support and distributed file systems.
More is the pity.

Of course, much of what drives the Windows platform success has to do
with its broad base of applications, largely driven by the availability
of powerful inexpensive hardware. The OS, or its structure, has
surprisingly little to do with why the general public buys Windows.

So maybe this boils down to a “GM versus Shelby” argument. Each has
their place in the world (I’ve got space in my garage for the Shelby you
don’t want, by the way…) Of course, for engineers, we often enjoy
working with Shelby but make our living working with GM…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

That person whom you quoted claims that the performance problem of Mach was
in implementation. That could be true. But it is only a claim, and I doubt
it.

As far as I know, OS/2 isn’t/wasn’t a micro-kernel OS, not in the sense of
having a small kernel that is the sole party to talk to hardware directly.
And, for me, that’s the crux of the micro-kernel. The features you cite,
such as minimality (“don’t put it in the kernel if it doesn’t have to be
there”), are pretty much motherhood and so not distinguishing.

Yes, Windows has those other features, for example, layering. But that
layering not the near-hermetic partitioning characteristic of micro-kernels.

–
James Antognini
Windows DDK and WDK Support

This posting is provided “AS IS” with no warranties, and confers no rights.

“Tony Mason” wrote in message news:xxxxx@ntfsd…
And those articles do seem to support my contention. For example, from
one of the articles I grabbed on the first page:

“Mach’s performance is a result of design and implementation not the
(\mu)-kernel concept!”

And a nicely put definition:

Micro-kernel Design Principles

Minimality:
If it doesn’t have to be in the kernel, it shouldn’t be in the
kernel
Appropriate abstractions
which can be made fast
and allow efficient implementation of services
Well written:
It pays to shave a few cycles off
TLB refill handler or the IPC path
Unportable:
must be targeted to specific hardware

$.$
no problem if it’s small, and higher layers are portable
$.$
Example: Liedtke reports significant rewrite of memory
management when porting from 486 to Pentium
==>
``abstract hardware layer’’ is too costly

I didn’t make this up - this is right out of some slides of an academic
class - right there on the first page of the Google search you
suggested. MY reading of these characteristics sounds like a very
good fit for the design goals of the components in Windows.

Again, a little searching told me that OS/2 contained a microkernel (I
found articles about IBM licensing it to third parties). Workplace OS
was a bit of a disaster, but from what I could tell that’s more related
to the way that IBM works than the underlying technology.

Well, I’d thought of talking about the nicely architected isolation
layer in Windows as being a feature. You seem to view that microkernel
influence as some sort of horrid past that needs to be hidden.

From that, it seems you have a prejudice against a particular
architecture; that’s fine and it certainly beats the C/C++ debate that
seems to war on here every so often. But your prejudice doesn’t agree
with my hands-on experience. My observation intended to be anything
other than a complement for the architecture of the Windows OS. I think
the OS is actually very well architected and works amazingly well in the
face of user mode components that seem hell-bent on taking an excellent
OS base and turning it into Windows 3.0.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Antognini
[MSFT]
Sent: Friday, August 19, 2005 7:41 PM
To: ntfsd redirect
Subject: Re:[ntfsd] On micro kernels and OS alternatives

Scurrilous or not, that’s the reputation. I just did a Google search on
“microkernel performance,” and the first 5-6 hits I eyeballed speak of
reputation/perception. Some argue with that, but it is what they
address.

To me, “micro-kernel” means encapsulation or isolation of a true OS
(speaks
to the hardware). I don’t see the connection between that and capability
at,
say, distributed systems.

I’m not aware of any micro-kernel OS that IBM shipped, none at least
that
had any longevity and wide use.

–
James Antognini
Windows DDK and WDK Support

This posting is provided “AS IS” with no warranties, and confers no
rights.

“Tony Mason” wrote in message news:xxxxx@ntfsd…
The characterization of microkernels as having a “poor reputation” due
to performance is scurrilous - I’d like to see the empirical data to
back up that accusation.

One of the most capable systems on which I’ve ever had the privilege to
work was a true micro-kernel, message passing OS - even the file system
ran in user mode. It had features that even now would be a struggle on
Windows (15 years ago we saw heterogenous process migration, which we
thought was interesting at the time but since we’d had process migration
for quite a while at that point - you know, where processes move from
computer to computer - we didn’t think it was that spectacular).

The list of micro-kernel OS systems is legion. That would include
Amoeba (someone was trashing it a few weeks ago in NTDEV for some
reason, no doubt because the didn’t like Tannenbaum’s quirky coding
style or something equally important), Accent (that was the microkernel
squished together with UNIX to become Mach), Chorus, V, etc. OSF/1 was
based upon Mach - both the monolithic version and eventually the
micro-kernel version. Performance was not the thing developers or users
seemed to complain about.

Of course performance is highly subjective; even today the Windows
system on which I operate seems to me to have horrible performance
characteristics (why, for example, does IE hang when Outlook cannot
contact my Exchange server?) in comparison to how V functioned for me
15+ years ago on hardware that was nowhere near as capable as what we
have today (Sun 2 workstations anyone?)

Conceptually, microkernel systems solve certain classes of problems
(e.g., distributed systems) extremely well. Of course, just like in the
real world, specific implementations can vary dramatically in terms of
actual performance.

IBM has had multiple micro-kernel based OS projects and as far as I know
they’ve shipped such products. I’m not sure how much influence OSF/1
had on AIX, but given that AIX 5 has the Open Group’s blessing there
must be some…

Windows incorporates numerous OS concepts that were bubbling in the
1980s - message passing, clear encapsulation layers (particularly from
hardware,) platform independence, etc. The concept of journaling file
systems also came out of that same time period (e.g., Cedar) and brought
us NTFS (which wasn’t the first journaling file system but is certainly
the most successful in the Windows arena).

There are a number of ideas from that era that sadly have not survived
so well, such as distributed OS support and distributed file systems.
More is the pity.

Of course, much of what drives the Windows platform success has to do
with its broad base of applications, largely driven by the availability
of powerful inexpensive hardware. The OS, or its structure, has
surprisingly little to do with why the general public buys Windows.

So maybe this boils down to a “GM versus Shelby” argument. Each has
their place in the world (I’ve got space in my garage for the Shelby you
don’t want, by the way…) Of course, for engineers, we often enjoy
working with Shelby but make our living working with GM…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

I’ve always suspected that Windows was designed as a true microkernel
architecture that was (for some reason) brought closer to a
monolithic kernel before it shipped. Look at the “privileged
subsystems” and LPC facilities, etc., in addition to the obvious
separation of components within ntoskrnl. If my conjecture is right,
do any of you who are more in the know than I am know why the
decision was made to ship a (more) monolithic kernel? Or was the
architecture we have now truly the original design?

Just curious.

-sd

On Aug 19, 2005, at 7:05 PM, Tony Mason wrote:

And those articles do seem to support my contention. For example,
from
one of the articles I grabbed on the first page:

“Mach’s performance is a result of design and implementation not the
(\mu)-kernel concept!”

And a nicely put definition:

Micro-kernel Design Principles

Minimality:
If it doesn’t have to be in the kernel, it shouldn’t be in the
kernel
Appropriate abstractions
which can be made fast
and allow efficient implementation of services
Well written:
It pays to shave a few cycles off
TLB refill handler or the IPC path
Unportable:
must be targeted to specific hardware

$.$
no problem if it’s small, and higher layers are portable
$.$
Example: Liedtke reports significant rewrite of memory
management when porting from 486 to Pentium
==>
``abstract hardware layer’’ is too costly

I didn’t make this up - this is right out of some slides of an
academic
class - right there on the first page of the Google search you
suggested. *MY* reading of these characteristics sounds like a very
good fit for the design goals of the components in Windows.

Again, a little searching told me that OS/2 contained a microkernel (I
found articles about IBM licensing it to third parties). Workplace OS
was a bit of a disaster, but from what I could tell that’s more
related
to the way that IBM works than the underlying technology.

Well, I’d thought of talking about the nicely architected isolation
layer in Windows as being a feature. You seem to view that
microkernel
influence as some sort of horrid past that needs to be hidden.

From that, it seems you have a prejudice against a particular
architecture; that’s fine and it certainly beats the C/C++ debate that
seems to war on here every so often. But your prejudice doesn’t agree
with my hands-on experience. My observation intended to be anything
other than a complement for the architecture of the Windows OS. I
think
the OS is actually very well architected and works amazingly well
in the
face of user mode components that seem hell-bent on taking an
excellent
OS base and turning it into Windows 3.0.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Antognini
[MSFT]
Sent: Friday, August 19, 2005 7:41 PM
To: ntfsd redirect
Subject: Re:[ntfsd] On micro kernels and OS alternatives

Scurrilous or not, that’s the reputation. I just did a Google
search on
“microkernel performance,” and the first 5-6 hits I eyeballed speak of
reputation/perception. Some argue with that, but it is what they
address.

To me, “micro-kernel” means encapsulation or isolation of a true OS
(speaks
to the hardware). I don’t see the connection between that and
capability
at,
say, distributed systems.

I’m not aware of any micro-kernel OS that IBM shipped, none at least
that
had any longevity and wide use.

–
James Antognini
Windows DDK and WDK Support

This posting is provided “AS IS” with no warranties, and confers no
rights.

“Tony Mason” wrote in message news:xxxxx@ntfsd…
> The characterization of microkernels as having a “poor reputation” due
> to performance is scurrilous - I’d like to see the empirical data to
> back up that accusation.
>
> One of the most capable systems on which I’ve ever had the
> privilege to
> work was a true micro-kernel, message passing OS - even the file
> system
> ran in user mode. It had features that even now would be a
> struggle on
> Windows (15 years ago we saw heterogenous process migration, which we
> thought was interesting at the time but since we’d had process
> migration
> for quite a while at that point - you know, where processes move from
> computer to computer - we didn’t think it was that spectacular).
>
> The list of micro-kernel OS systems is legion. That would include
> Amoeba (someone was trashing it a few weeks ago in NTDEV for some
> reason, no doubt because the didn’t like Tannenbaum’s quirky coding
> style or something equally important), Accent (that was the
> microkernel
> squished together with UNIX to become Mach), Chorus, V, etc. OSF/1 was
> based upon Mach - both the monolithic version and eventually the
> micro-kernel version. Performance was not the thing developers or
> users
> seemed to complain about.
>
> Of course performance is highly subjective; even today the Windows
> system on which I operate seems to me to have horrible performance
> characteristics (why, for example, does IE hang when Outlook cannot
> contact my Exchange server?) in comparison to how V functioned for me
> 15+ years ago on hardware that was nowhere near as capable as what we
> have today (Sun 2 workstations anyone?)
>
> Conceptually, microkernel systems solve certain classes of problems
> (e.g., distributed systems) extremely well. Of course, just like
> in the
> real world, specific implementations can vary dramatically in terms of
> actual performance.
>
> IBM has had multiple micro-kernel based OS projects and as far as I
> know
> they’ve shipped such products. I’m not sure how much influence OSF/1
> had on AIX, but given that AIX 5 has the Open Group’s blessing there
> must be some…
>
> Windows incorporates numerous OS concepts that were bubbling in the
> 1980s - message passing, clear encapsulation layers (particularly from
> hardware,) platform independence, etc. The concept of journaling file
> systems also came out of that same time period (e.g., Cedar) and
> brought
> us NTFS (which wasn’t the first journaling file system but is
> certainly
> the most successful in the Windows arena).
>
> There are a number of ideas from that era that sadly have not survived
> so well, such as distributed OS support and distributed file systems.
> More is the pity.
>
> Of course, much of what drives the Windows platform success has to do
> with its broad base of applications, largely driven by the
> availability
> of powerful inexpensive hardware. The OS, or its structure, has
> surprisingly little to do with why the general public buys Windows.
>
> So maybe this boils down to a “GM versus Shelby” argument. Each has
> their place in the world (I’ve got space in my garage for the
> Shelby you
> don’t want, by the way…) Of course, for engineers, we often enjoy
> working with Shelby but make our living working with GM…
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/
> article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

7

My guess is that there are three reasons: performance, performance, and
performance.

----- Original Message -----
From: “Steve Dispensa”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, August 20, 2005 1:35 PM
Subject: Re: [ntfsd] On micro kernels and OS alternatives

> I’ve always suspected that Windows was designed as a true microkernel
> architecture that was (for some reason) brought closer to a monolithic
> kernel before it shipped. Look at the “privileged subsystems” and LPC
> facilities, etc., in addition to the obvious separation of components
> within ntoskrnl. If my conjecture is right, do any of you who are more in
> the know than I am know why the decision was made to ship a (more)
> monolithic kernel? Or was the architecture we have now truly the original
> design?
>
> Just curious.
>
> -sd
>
> On Aug 19, 2005, at 7:05 PM, Tony Mason wrote:
>