Microkernel discussion continued....

NTDEV
21

I think because web/database programming and application/driver programming are different things.
There is only one common thing is this:

Both of them are called “programmer” . Yes, high school script kiddies are programmer too.

They are “programmer” too, but they are not engineer as i tried to explain above. Web or etc programmers don’t “need” to learn memory management, object management, interlocking, threading, etc… Because web or database programming are not related these things.

This is what makes difference. You all kernel developers “have to” learn these stupid things. Because this is kernel developers job. This what give you power to code whatever you want. But they have no much choices. Always same things.

Nobody humiliated web programmer or .NET guys. But there are lots of differences.

In 2006, 2 years ago, I wrote C# applications, database stuff didn’t know C++(native code).

I was using Sygate Firewall in my computer then i decided to write such a firewall program. I asked if there is a way to code with C#. Answer: Of course not. So i decided that learn C\C++. I said: “Peh, How it could be difficult. I will learn and and after continue to write .NET code”.

But when i learn pointer manipulation, v-table… see run-time errors and try to debug them.
I understood that C# is just a script coding, althuogh .NET compiler generates PE file, Although they use C#/java to make an OS. Now high school kids can make an OS.

After 2 years, today i am studying my last chapter in driver programming book. I can understand everything. I enjoy this very much. I am remembering myself when i was writing C# server/client chat app., that boy knew nothing. But it worked. I knew nothing but it worked anyway. I hope i can explain.

Get your “job” done? But which job? I think There is no “job” remains when start to use Garbage collector.

I want to give you difficulty rate among programming devs. IMHO
if

  • web/database develeopers job: 1x
  • application developer(MFC,COM) : 5x
  • kernel guy : 15x
22

>They have reduced the market price to the point where

it isn’t attractive for me.

But YOU aren’t important, right? :slight_smile:

That’s elitism. “My job is more important than yours because I have to
think harder.”

That is capitalism. If a job is harder to do, it should draw more pay all
other things being equal.

“I’m a driver programmer, therefore I’m better than
you, you lowly little web coder.”
Web and database programmers already have better
tools.

Kernel development isn’t hard due to a lack of tools. It is hard because it
solves a much much more complex set of problems than web programming, (I
don’t find web tools to be all that great anyway.) But, interfacing with
hardware in the bowels of the OS is just a tougher deal today. I don’t
think I am better than a web programmer, I think I have worked harder and
mastered a tougher skill.

But, given all of that, I am ALL for them making an easier more robust
driver model. I don’t think people should be able to make a living doing
what I do. I never have, it never made sense to me. I make a living
because I have spent the time to learn dozens of Microsoft conventions and
rules and I know what a hardware register is :slight_smile: That is a real shame. A
managed environment would be great.

That said, I think we are at least 10 years away from something like that
having any real penetration in our field. I am still not convinced it can
be done. There has been some research and such, but solving the hardware
problem that Windows has solved is WAY more complex than any other operating
system has ever dealt with. Until a managed solution can handle 95+% of the
hardware that plugs into Windows today, it ain’t real. So, to me the more
important avenue of attack is what can be done with what we have today.
Samples and documentation there is just no substitute.

Bill M.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@hotmail.com wrote:
>> Tim,
>>
>>> Managed code is another step in this evolution. It lets me do 10 times
>>> as much work with
>>> each line of code, plus the managed framework can keep me from hurting
>>> myself.
>>>
>>
>> Well, then go and do web design or at least database programming. What
>> are you doing in the kernel world then???
>>
>
> Why do you think they should be fundamentally different? Performance?
> That is more and more a non-issue. Sure, some classes of drivers will
> always need to count microseconds (10 gigabit Ethernet…), but that set
> is growing smaller and smaller. Reliability? Having drivers be managed
> code under the watchful eye of a framework is certainly going to improve
> reliability and recoverability.
>
> Look, to a certain extent, I’m playing devil’s advocate here, and
> intentionally poking at some sacred cows. There is no denying that
> there is a pervasive sense of elitism in this mailing list, and I’m as
> guilty as the rest. “I’m a driver programmer, therefore I’m better than
> you, you lowly little web coder.” I think that’s largely nonsense. If
> I can get the job done by using better tools, then that makes me a more
> productive programmer. Web and database programmers already have better
> tools. Why shouldn’t I have the same benefits?
>
> By the way, I would LOVE to do web programming for a living. I find it
> interesting and fascinating. However, experience has showed me that
> there are too many high school kids who are willing to do a hack-up job
> for $10 an hour. They have reduced the market price to the point where
> it isn’t attractive for me.
>
>>> Only if you are a hobbyist.
>>>
>>
>> Well, I would say most of us are some kind of “hobbyists” here -
>> otherwise, instead of writing drivers, we would rather do . NET
>> programming, which is perfectly reasonable approach for someone who just
>> wants to do the work quickly and get “a quick buck” without thinking too
>> much…
>>
>
> That’s elitism. “My job is more important than yours because I have to
> think harder.” A managed code framework can relieve you from having to
> think about stupid things: memory management, object management,
> interlocking, threading, etc. It provides you with guarantees, so you
> can get your job done without having to think so hard about problems
> that have already been solved.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

23

> solving the hardware problem that Windows has solved is WAY more complex than

any other operating system has ever dealt with.

This is true. However, just ask yourself “Why does it work this way??? Where does all this complexity come from and why all other OSes don’t have to deal with it???”

At this point the inefficiency of microkernel design becomes obvious. Although Windows NT puts all its drivers into a privileged mode, it terms of architecture and IO model it is essentially a microkernel-based system under which drivers and subsystems have to communicate with one another via IO Manager and by pre-defined mechanisms (i.e. IRPs) that are the same for each and everyone, regardless of driver type - the only difference is in IRP codes and subcodes. This is why you get a bunch of PnP IRPs that you have to deal with when you write drivers for hardware devices (these IRPs are, again, the same for each and everyone, regardless of device type); recursive calls to FSD from MM and CM when you write file system drivers and filters, etc, etc,etc. As a result, you end up with a messy code with huge switch-case block and billions of if blocks ; have to figure out which IRPs and with which minor subcode your driver has to handle; and, in general, have to deal with a lot of confusing stuff ( I already don’t mention the fact that dealing with various IRP completion scenarios is not that simple either).

Now compare it to Linux driver model. In your module entry, first of all, you register the lower edge of your driver with callbacks that will be invoked by the appropriate subsystem (PCI, USB,etc). Upon receiving a callback to your probe() handler, you do all initialization that is appropriate for your device (it is understandable that initialization of, say, PCI device is totally different from that of, say, USB one), and then register its upper edge (i.e. character or block or network device) with callbacks that are, again, appropriate only for a given type of device. For example, network device’s interface is totally different from that of character device. As a result, you end up with just a few callbacks, and you know perfectly well under which circumstances they will get invoked, as well as how to handle them. If you look at the Linux source, you will see that vast majority of Linux drivers are implemented in a single source file…

Anton Bassov

24

> Why do you think they should be fundamentally different? Performance?

Correct…

That is more and more a non-issue.

Only if your driver/OS component happens to be relatively dormant. However, the more often it is invoked and the more processes rely upon it it, the more concerned about the performance issues you are. …

If I can get the job done by using better tools, then that makes me a more productive programmer.
Web and database programmers already have better tools. Why shouldn’t I have the same benefits?

You seem to have answered your own question. Here we go:

[begin quote]

By the way, I would LOVE to do web programming for a living. I find it interesting and fascinating.
However, experience has showed me that there are too many high school kids who are willing to do a hack-up job for $10 an hour. They have reduced the market price to the point where it isn’t attractive for me.

[end quote]

You just cannot eat cake and have it at the same time. Therefore, if you have the same tools to do your job that these kids have to do theirs, again, they will be able to do your job and push your rates down to 10$ an hour. After all, it is neither you nor these kinds who do the job - the whole thing is done by the tool. Therefore, I am afraid you are just trying to bite the hand that feeds you.

Anton Bassov

25

>This is true. However, just ask yourself "Why does it work this way???

Where does all this complexity come from and why all other OSes don’t have
>to deal with it???"

While we are at it why don’t we ask why the x86 architecture is so screwed
up compared to just about any other processor architecture on the market?

Or we could just ask what OS runs on 95+% of all PCs and is the most likely
to be a money maker for those developing software for it?

I am DEFINITELY not saying Linux is technologically superior to Windows in
ANY shape or form. However, what I am saying is who cares? The best
technologies rarely win. You have to go with a winner.

That said, I do think the fact that Windows can run just about any hardware
on any PC platform from just about any manufacturer is absolutely friggin
amazing and gives it technological bragging rights just on that fact. Linux
would roll over and play dead 7 ways from Sunday if you tried to really put
it through the hardware paces that Windows deals with every day. I think
that is true of any other operating system. But, fortunately, I don’t think
we will ever be able to prove that statement :slight_smile:

Bill M.

wrote in message news:xxxxx@ntdev…
> solving the hardware problem that Windows has solved is WAY more complex
> than
> any other operating system has ever dealt with.

This is true. However, just ask yourself “Why does it work this way??? Where
does all this complexity come from and why all other OSes don’t have to deal
with it???”

At this point the inefficiency of microkernel design becomes obvious.
Although Windows NT puts all its drivers into a privileged mode, it terms
of architecture and IO model it is essentially a microkernel-based system
under which drivers and subsystems have to communicate with one another via
IO Manager and by pre-defined mechanisms (i.e. IRPs) that are the same for
each and everyone, regardless of driver type - the only difference is in IRP
codes and subcodes. This is why you get a bunch of PnP IRPs that you have to
deal with when you write drivers for hardware devices (these IRPs are,
again, the same for each and everyone, regardless of device type); recursive
calls to FSD from MM and CM when you write file system drivers and filters,
etc, etc,etc. As a result, you end up with a messy code with huge
switch-case block and billions of if blocks ; have to figure out which IRPs
and with which minor subcode your driver has to handle; and, in general,
have to deal with a lot of confusing stuff ( I already don’t mention the
fact that dealing with various IRP completion scenarios is not that simple
either).

Now compare it to Linux driver model. In your module entry, first of all,
you register the lower edge of your driver with callbacks that will be
invoked by the appropriate subsystem (PCI, USB,etc). Upon receiving a
callback to your probe() handler, you do all initialization that is
appropriate for your device (it is understandable that initialization of,
say, PCI device is totally different from that of, say, USB one), and then
register its upper edge (i.e. character or block or network device) with
callbacks that are, again, appropriate only for a given type of device. For
example, network device’s interface is totally different from that of
character device. As a result, you end up with just a few callbacks, and you
know perfectly well under which circumstances they will get invoked, as well
as how to handle them. If you look at the Linux source, you will see that
vast majority of Linux drivers are implemented in a single source file…

Anton Bassov

26

> While we are at it why don’t we ask why the x86 architecture is so screwed up

compared to just about any other processor architecture on the market?

Well, x86 is quite popular on desktops and laptops, but if you look at any other platform you would not notice it anywhere in the top 10. For example, when it comes to mobile devices, ARM is an absolute leader, and, despite all Intel’s efforts (like Atom processor), this gap is, apparently, going to widen more and more and more…

That said, I do think the fact that Windows can run just about any hardware on any PC platform
from just about any manufacturer is absolutely friggin amazing and gives it technological
bragging rights just on that fact. Linux would roll over and play dead 7 ways from Sunday if
you tried to really put it through the hardware paces that Windows deals with every day.

BOLLOCKS!!! FYI, Linux runs virtually on every piece of hardware in existence. If you look into its /arch
directory, you will see 24(!!!) folders with arch-specific code, and every of these architectures has various flavors. Just to give you idea, they think of x86 and x86_64 as just of different flavors of what they refer to as i686. When it comes to ARM, the variety of CPU-specific code is much,much wider, and the number of board-specific folders seems to be just countless. First get your facts right, and then start saying things…

Anton Bassov

27

> BOLLOCKS!!! FYI, Linux runs virtually on every piece of hardware in

existence.

Sure it does. How long have you been in software? I suspect not that long.
Just because someone got something running once or 100 times or a thousand
times successfully doesn’t mean anything. Just because someone puts a
driver in a directory doesn’t mean anything either. PCs are selling at a
rate of somewhere in the neighborhood of 20 million a month. Virtually all
of those are sold with Windows on board. That means hundreds of millions of
PCs running XP and Vista right now.

Linux would burst at the seams with this kind of volume. A one in a million
mistake probably rarely shows itself in Linux today. One in a million can
cripple Windows. Its a completely different scope. Sure, Linux may run on
some arcane architectures but again who cares? The money has been and still
is today in Windows, at least on the PC. No other operating system has ever
undergone the strain that Windows deals with everyday. You can claim Linux
is great all day…but again, we are soooo fortunate that we will probably
never be able to test that claim.

Bill M.

wrote in message news:xxxxx@ntdev…
>> While we are at it why don’t we ask why the x86 architecture is so
>> screwed up
>> compared to just about any other processor architecture on the market?
>
> Well, x86 is quite popular on desktops and laptops, but if you look at
> any other platform you would not notice it anywhere in the top 10. For
> example, when it comes to mobile devices, ARM is an absolute leader, and,
> despite all Intel’s efforts (like Atom processor), this gap is,
> apparently, going to widen more and more and more…
>
>
>> That said, I do think the fact that Windows can run just about any
>> hardware on any PC platform
>> from just about any manufacturer is absolutely friggin amazing and gives
>> it technological
>> bragging rights just on that fact. Linux would roll over and play dead 7
>> ways from Sunday if
>> you tried to really put it through the hardware paces that Windows deals
>> with every day.
>
> BOLLOCKS!!! FYI, Linux runs virtually on every piece of hardware in
> existence. If you look into its /arch
> directory, you will see 24(!!!) folders with arch-specific code, and every
> of these architectures has various flavors. Just to give you idea, they
> think of x86 and x86_64 as just of different flavors of what they refer to
> as i686. When it comes to ARM, the variety of CPU-specific code is
> much,much wider, and the number of board-specific folders seems to be just
> countless. First get your facts right, and then start saying things…
>
> Anton Bassov
>
>

28

Bill McKenzie wrote:

…

That said, I do think the fact that Windows can run just about any hardware
on any PC platform from just about any manufacturer is absolutely friggin
amazing and gives it technological bragging rights just on that fact. Linux
would roll over and play dead 7 ways from Sunday if you tried to really put
it through the hardware paces that Windows deals with every day.

Maybe this was true few years ago, but no more.
These days most of players on hardware and platform market
support Linux explicitly (take Intel, for example).
In other words, open source kernel today has exactly same or
better than Windows level of hardware & BIOS compatibility, *by design*.

And what about Windows… recently we witnessed “triumph” of Vista.
Partially this was due to increased requirements to hardware, esp. video.
So… Vista was the best and greatest gift of Microsoft to the Linux
community.

But yes, overall, Microsoft has created the PC compatible hardware
market, they actively drive many related hardware standards, and they
have WHQL.
Success of Linux on PC platform mostly has been created by Microsoft.

[ having said that… the show goes on, we’ll probably see hardware
platforms
made by design incompatible with open source: driven by DRM,
provider locking and similar “anti-democratic” requirements ]

–PA

29

A simple thing on this …

About a month ago, I had the same sort of discussion here …

As an example, Blue Ant bluetooth receiver does not work with linux.
It’s been popular for quite sometime and works under windows for quite
some time… Should I go find right drivers, or cookup drivers etc.

See this is where things from users perspective don’t catch up so nicely…

There is nothing like “Tested and true …”

-pro

Bill McKenzie wrote:

> BOLLOCKS!!! FYI, Linux runs virtually on every piece of hardware in
> existence.
>

Sure it does. How long have you been in software? I suspect not that long.
Just because someone got something running once or 100 times or a thousand
times successfully doesn’t mean anything. Just because someone puts a
driver in a directory doesn’t mean anything either. PCs are selling at a
rate of somewhere in the neighborhood of 20 million a month. Virtually all
of those are sold with Windows on board. That means hundreds of millions of
PCs running XP and Vista right now.

Linux would burst at the seams with this kind of volume. A one in a million
mistake probably rarely shows itself in Linux today. One in a million can
cripple Windows. Its a completely different scope. Sure, Linux may run on
some arcane architectures but again who cares? The money has been and still
is today in Windows, at least on the PC. No other operating system has ever
undergone the strain that Windows deals with everyday. You can claim Linux
is great all day…but again, we are soooo fortunate that we will probably
never be able to test that claim.

Bill M.

wrote in message news:xxxxx@ntdev…
>
>>> While we are at it why don’t we ask why the x86 architecture is so
>>> screwed up
>>> compared to just about any other processor architecture on the market?
>>>
>> Well, x86 is quite popular on desktops and laptops, but if you look at
>> any other platform you would not notice it anywhere in the top 10. For
>> example, when it comes to mobile devices, ARM is an absolute leader, and,
>> despite all Intel’s efforts (like Atom processor), this gap is,
>> apparently, going to widen more and more and more…
>>
>>
>>
>>> That said, I do think the fact that Windows can run just about any
>>> hardware on any PC platform
>>> from just about any manufacturer is absolutely friggin amazing and gives
>>> it technological
>>> bragging rights just on that fact. Linux would roll over and play dead 7
>>> ways from Sunday if
>>> you tried to really put it through the hardware paces that Windows deals
>>> with every day.
>>>
>> BOLLOCKS!!! FYI, Linux runs virtually on every piece of hardware in
>> existence. If you look into its /arch
>> directory, you will see 24(!!!) folders with arch-specific code, and every
>> of these architectures has various flavors. Just to give you idea, they
>> think of x86 and x86_64 as just of different flavors of what they refer to
>> as i686. When it comes to ARM, the variety of CPU-specific code is
>> much,much wider, and the number of board-specific folders seems to be just
>> countless. First get your facts right, and then start saying things…
>>
>> Anton Bassov
>>
>>
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>

30

And all these can happen from anyone. Until someone proven guilty,
everyone is innocent.

When this thing happens from open source, there is no direction to
follow in oder to bring them under justice ( So is the justice so far
…). Way too many parrots littered your house …

When it comes from a big company there is some windows of opportunity
for some people to make money, and those Big companies are aware about
this …

-pro

[ having said that… the show goes on, we’ll probably see hardware
platforms
made by design incompatible with open source: driven by DRM,
provider locking and similar “anti-democratic” requirements ]

–PA

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

31

Damn good thing I appreciate irony, because now I’m defending Linux of all things. Which I declare sucks.

This – and the description of the number of computers running Windows versus Linux – is correct for DESKTOP SYSTEMS only. I believe the industry has definitively accepted that Linux functions in the server world remarkably well and that it is at LEAST as reliable, and probably MORE reliable, in this application than Windows. And it performs well, too.

Desktops, with their varied hardware? Not so much.

What this all has to do with Microkernels and C# is beyond me, though. Both Linux AND Windows are implementations of long-outdated 1970’s OS technology, and we need to abandon this whole path to make real change. Arguing about Linux versus Unix versus windows is like trying to argue which of two identical twins is prettier, from an OS perspective. Oh, they each have their individual quirks… but the differences between them are much smaller than the differences between them and other alternatives.

Peter
OSR

32

My only argument was that arguing about which is technically superior is
pointless. Both because it just doesn’t matter and you can’t argue it.
Linux has not and hopefully never will run in the same environment as
Windows. Wasn’t talking server at all, but we can start a new thread on
that if you like?

So, you can say all you want about the greatness of Linux…who cares…for
PC products Windows is the king. Who cares whose I/O model is better? And
who can say?

Bill M.

wrote in message news:xxxxx@ntdev…
> Damn good thing I appreciate irony, because now I’m defending Linux of all
> things. Which I declare sucks.
>
>


>
> This – and the description of the number of computers running Windows
> versus Linux – is correct for DESKTOP SYSTEMS only. I believe the
> industry has definitively accepted that Linux functions in the server
> world remarkably well and that it is at LEAST as reliable, and probably
> MORE reliable, in this application than Windows. And it performs well,
> too.
>
> Desktops, with their varied hardware? Not so much.
>
> What this all has to do with Microkernels and C# is beyond me, though.
> Both Linux AND Windows are implementations of long-outdated 1970’s OS
> technology, and we need to abandon this whole path to make real change.
> Arguing about Linux versus Unix versus windows is like trying to argue
> which of two identical twins is prettier, from an OS perspective. Oh,
> they each have their individual quirks… but the differences between them
> are much smaller than the differences between them and other alternatives.
>
> Peter
> OSR
>
>
>

33

xxxxx@hotmail.com wrote:

> While we are at it why don’t we ask why the x86 architecture is so screwed up
> compared to just about any other processor architecture on the market?
>

Well, x86 is quite popular on desktops and laptops, but if you look at any other platform you would not notice it anywhere in the top 10. For example, when it comes to mobile devices, ARM is an absolute leader, and, despite all Intel’s efforts (like Atom processor), this gap is, apparently, going to widen more and more and more…

The irony, of course, is that Intel is one of the largest sellers of ARM
processors. That’s exactly what the Xscale is.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

34

> The irony, of course, is that Intel is one of the largest sellers of ARM processors.

That’s exactly what the Xscale is.

The true irony here is that, for the reasons better known to themselves, they abandoned this direction, despite being leaders in it. Wake up - they sold Xscale to Marvell Technology Group two years ago, and, instead of pursuing ARM direction in which they were ultimate leaders, concentrated their efforts on trying to take x86-based processors to the mobile devices. Therefore, when you see PXAxxx, don’t associate it with Intel any more - now they compete with it. Apparently, it must be a great fun to compete with the technology that you have actually invented…

Anton Bassov

35

This should be it … Seriously, this is it …

Before anyone comes up with comments etc., please please provide us
scientific/engineering analysis … Not just (s)he has a nice mole on
right cheek.

Taking the libery now, … Thanks Mr. tautologist :slight_smile:

-pro

Who cares whose I/O model is better?

And
who can say?

Bill M.

36

> What this all has to do with Microkernels and C# is beyond me, though. Both Linux

AND Windows are implementations of long-outdated 1970’s OS technology,

The funniest thing here is that, unlike Linux, Windows NT was not meant to be “long-outdated 1970’s OS technology” from the very, very beginning - they have adopted it gradually, and did it solely for the reasons of performance. Please read “Tannenbaum vs Torvalds” discussion again - it took place when Windows NT was still under a development, so that , at the time, Tannenbaum refers to it as to something “progressive”. Apparently, it was a great fun for him to watch how “progressive microkernel-based OS”
started moving towards “outdated monolithic” design immediately after having been ACTUALLY tested in real-life conditions, because"progressive" design turned out simply unworkable in practice, for the performance reasons …

Basically, what we have now is the OS, under which components running in the privileged mode communicate by means of IO model that was designed with microkernel in mind. In other words, they
took the worst from both designs - somehow they managed to combine insecurity, associated with monolithic kernel, with inefficiency and complexity associated with microkernel…

Please check another “long thread” where Doron and I discuss this topic - it looks like he finally accepted my point that even if you want to filter a driver while having no access to its source code,
currently known Windows NT IO model is far from being the best, let alone the only one, possibility of doing it…

Anton Bassov

37

> for PC products Windows is the king.

Really??? Are you saying that one has to stand a queue in order to get RTM Vista??? IIRC, the only way they distribute it is by imposing it on end users by offering OEMs to pre-install it and giving end user no choice. Therefore, when it comes to the official statistics, I am on the list of Vista users, because my machine came with this “masterpiece” pre-installed on it, and the fact that the very first thing I did was erasing it from my hard drive is, apparently, not recorded anywhere…

BTW, when it comes to Vista, what I would strongly advise all readers of this list who use Vista to do is to *ACTUALLY* read their EULA - they may find something that they would deem totally unacceptable for themselves in its terms (please note that this particular condition is specific only to Vista users - IIRC, users of all previously known MSFT-produced OSes were not subjected to it)…

Anton Bassov

38

There were elements of Microkernel design in Windows NT, as Mach was fresh in the minds of the developers at the time… and the “microkernel” approach of NT was made a great deal of in the marketing literature.

Ooops! There you go again, making unsupported assertions.

NT’s “microkernel-ness” was really limited to the idea that:

a) The executive would use an abstract interface to access kernel-level functionality. The kernel would use a abstract interface to access platform-specific functionality (as implemented in the HAL).

b) Each executive subsystem (IO, MM, Ex, CC, etc) was to be distinct and have a “formally defined” set of interfaces.

c) Applications would be clients of and only communicate with user-mode OS Emulation Subsystems. The OS Emulation Subsystem would then talk to the underlying kernel-mode code.

This design didn’t turn out to be “unworkable in practice.” Much of it survives. Some of it was lost due to lack of interest (such as the “formal interfaces” and borders between executive subsystems). Some of it was lost chasing smaller footprint (there was a HUGE amount of effort done on reducing the memory footprint of Windows NT back in the day… and just as this work was completed, the price of RAM dropped like a rock). Remember, a decent Windows NT system had 16MB of memory (that IS MB, not GB).

And some of the original design WAS lost in the pursuit of performance. You can only push a Pentium Pro so hard, you know.

NONE of this is intended to suggest that the original design approaches were “unworkable in practice”.

You are, once again, grossly mis-informed and talking about something about which you apparently know little.

The Windows IO model does NOT derive from microkernel architecture. It derives from VMS (released 1978), which derives from RSX-11M (released 1973… after a whopping 18 month development effort!). The IO model (with IRPs being forwarded from device to device, and with DPCs being queued as an alternative to running at DIRQL) in these operating systems is VERY similar to that of Windows NT. I can state this as a fact, having written kernel mode code for all of them.

Peter
OSR

39

Nope, he meant to say it is made in king county, perhaps !!!

-pro

> for PC products Windows is the king.

Really??? Are you saying that one has to stand a queue in order to get RTM

40

Peter,

You are, once again, grossly mis-informed and talking about something about which you
apparently know little. The Windows IO model does NOT derive from microkernel architecture.

Actually, I really have no clue what it derives from . However, if you think carefully about the microkernel design, it will (hopefully) become obvious to you that, no matter what NT IO model is derived from, it is just an ideal mechanism for someone who designs a microkernel.

Let’s say you decide to design a microkernel, but have no idea about driver model/system interfaces, because you want your microkernel to work with various driver models so that it can be possibly used by different OSes. Therefore, you decide to implement some flexible , extensible and relatively inexpensive IPC mechanism that the driver model of any description, no matter what it is like, can be subsequently built upon. What are you going to do???

If you think about it carefully, you will realize that in such case NT IO model is just an ideal option for you.
Look - you have a packet that describes IO buffers and their sizes, request type, major and minor function codes, plus requesting thread ID. As a microkernel designer, all you have to do is to map IO buffers into the callee’s IO space before passing the request ( or vice versa upon the request completion - this is what thread ID is for), and pass it to some pre-defined by callee’s module function that is the same for all types of requests. This is the only thing you should be concerned about, and drivers/subsystems will do the rest simply by defining function major and minor codes - you can build any driver model with any interface on top of this mechanism…

However, if, from the very beginning, you know that all system components will reside in the same address space, this model becomes simply cumbersome and inefficient - what is the point of making drivers pass requests to one another at the time when they can simply register multiple callbacks with the OS???

Are you still arguing that NT IO model is naturally microkernel-based???

Anton Bassov