RE: A new version of windows...

OSR_Community_User-11 · October 3, 2001, 1:01pm

Peter,

I got my copy of the NT insider today, and I read your “pontificates”
article with a great deal of interest. I have two thoughts on this…

I have always thought that there should be some “intermediate” level of
drivers, where non-essential (yet non user-mode) code should reside. It
always bothered me that in X86-land, only two levels of hardware protection
were used: ring-3 and ring-0. What about rings 1 & 2? Why all-or-nothing?
I realize that originally the common code base was meant to support
different types of processors (MIPS, PowerPC, Alpha, X86), but that’s all
pretty much history now (ia64 excepted), and I venture to guess that 96% of
the installed 2000/XP platforms are/will-be X86-based anyway (why else did
Compaq drop support for the Alpha?). Why not let the hardware share some of
the burden as well?
You are absolutely right - a lot of the pseudo-driver code does need to
be kicked out of kernel-mode space. Please understand where I’m coming
from. I don’t write KMDs for a living. Roughly 85% of the code I write is
user-mode. I chose the NT platform for it’s stability, not it’s speed. But
I was forced into learning and writing KMDs because I had to support my
company’s legacy I/O acquisition cards, cards that only needed simple port
I/O and interrupt capability. I’ll bet there are a lot of other devices out
there that fall into this category, the category of non-essential, yet
hardware-driven. The pressures of market demands and company deadlines
makes *REALLY* learning kernel mode drivers difficult and expensive. I’m
willing to bet that there are very few people out there that have your level
of expertise in device driver writing. Most people just want to be able to
get at their hardware, and thus they learn the bare minimum to get the job
done. Are these those kinds of device drivers you want to give free-reign,
to put on an equal footing with the OS? I don’t think so…

How many times have you seen somebody post a question like “how do I share
memory between my user-mode app and my driver?” - chances are, the poor soul
was just trying to talk to his simple hardware - he wasn’t trying to write a
file-system or network driver. There really SHOULD be a sandbox for these
types of drivers. Maybe someday there will.

Writing your article was a great start toward this effort. You’ve got my
100% support.

Regards,

Bill Christie, Software Engineer
Link Engineering Company
43855 Plymouth Oaks Blvd.
Plymouth, MI 48170
www.linkeng.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · October 4, 2001, 3:08am

> always bothered me that in X86-land, only two levels of hardware protection

were used: ring-3 and ring-0. What about rings 1 & 2? Why all-or-nothing?
I realize that originally the common code base was meant to support
different types of processors (MIPS, PowerPC, Alpha, X86),

Yes. Only x86 has 4 levels, other CPUs have 2.

pretty much history now (ia64 excepted), and I venture to guess that 96% of

Still not history for Windows CE.

Compaq drop support for the Alpha?). Why not let the hardware share some of
the burden as well?

Occam’s Razor is possibly an answer. No need in it.

of expertise in device driver writing. Most people just want to be able to
get at their hardware

Then use “smaller” Windows which deserved the reputation of “muzdie” due to exactly this reason (among others like global data and
Win16Lock). Hope MS will not open the hardware access for user mode - this will ruin the stability.
So, going away from MS-DOS mentality seems to be the only solution.

You can also use a hack - call some Kexxx functions to allow your user-mode app to use IN/OUT instructions, but surely not
interrupts or DMA.
The applet which shows the mobo/CPU temperature uses this.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Ilya_Lifshits · October 4, 2001, 9:03am

Dear Bill,

Regarding your second paragraph:
I don’t write KMDs for a living. Roughly 85% of the code I write is
user-mode …
I was forced into learning and writing KMDs because I had to support my
company’s
legacy I/O acquisition cards … The pressures of market demands and
company deadlines
makes *REALLY* learning kernel mode drivers difficult and expensive …
The company I work for (Jungo) provides tools for the driver developers
community to solve exactly
this problem. Jungo’s tool - WinDriver - provide the means to create a
device driver for such custom
hardware without having to learn DDK and kernel programing. Programing is
done in user mode
(while for performance critical parts of the code there’s a special tool to
plug it in the kernel).
Hope this information will be of help.

Best Regards,
Ilya Lifshits.

R&D
Jungo Ltd.
Email: xxxxx@jungo.com
Web: http://www.jungo.com
Phone: 1-877-514-0537(USA) +972-9-885-8611 (Worldwide) Ext. 117
Fax: 1-877-514-0538(USA) +972-9-885-0619 (Worldwide)

At 12:57 PM 10/3/2001 -0400, Bill Christie wrote:

Peter,

I got my copy of the NT insider today, and I read your “pontificates”
article with a great deal of interest. I have two thoughts on this…

I have always thought that there should be some “intermediate” level of
drivers, where non-essential (yet non user-mode) code should reside. It
always bothered me that in X86-land, only two levels of hardware protection
were used: ring-3 and ring-0. What about rings 1 & 2? Why all-or-nothing?
I realize that originally the common code base was meant to support
different types of processors (MIPS, PowerPC, Alpha, X86), but that’s all
pretty much history now (ia64 excepted), and I venture to guess that 96% of
the installed 2000/XP platforms are/will-be X86-based anyway (why else did
Compaq drop support for the Alpha?). Why not let the hardware share some of
the burden as well?

You are absolutely right - a lot of the pseudo-driver code does need to
be kicked out of kernel-mode space. Please understand where I’m coming
from. I don’t write KMDs for a living. Roughly 85% of the code I write is
user-mode. I chose the NT platform for it’s stability, not it’s speed. But
I was forced into learning and writing KMDs because I had to support my
company’s legacy I/O acquisition cards, cards that only needed simple port
I/O and interrupt capability. I’ll bet there are a lot of other devices out
there that fall into this category, the category of non-essential, yet
hardware-driven. The pressures of market demands and company deadlines
makes *REALLY* learning kernel mode drivers difficult and expensive. I’m
willing to bet that there are very few people out there that have your level
of expertise in device driver writing. Most people just want to be able to
get at their hardware, and thus they learn the bare minimum to get the job
done. Are these those kinds of device drivers you want to give free-reign,
to put on an equal footing with the OS? I don’t think so…

How many times have you seen somebody post a question like “how do I share
memory between my user-mode app and my driver?” - chances are, the poor soul
was just trying to talk to his simple hardware - he wasn’t trying to write a
file-system or network driver. There really SHOULD be a sandbox for these
types of drivers. Maybe someday there will.

Writing your article was a great start toward this effort. You’ve got my
100% support.

Regards,

Bill Christie, Software Engineer
Link Engineering Company
43855 Plymouth Oaks Blvd.
Plymouth, MI 48170
www.linkeng.com

You are currently subscribed to ntdev as: xxxxx@jungo.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · October 5, 2001, 12:55am

If you can constrain the failures so that they occur in the context of a sub-graph of drivers,
rather than at random places in support functions called by the drivers, and the
memory allocations for the sub-graph are disjoint from other sub-graphs, then its
conceptually straight forward to “rip-out” the subgraph of drivers and free their memory, and return errors
on subsequent operations until closed. Using the MMUs to ensure rules are followed
is nice, but not necessary for the majority of the cases.

The more important is the question of whether the system is useful after you have done this.
In my experience, the crashes tend to occur in the in something related to what you are using
the machine for, rather than due to some secondary function. For example, the video
driver crashes when you are playing the fancy video game, rather than when you are running Word.

I actually built some recovery into the kernel on a fault-tolerant system. In this case, the OS/hardware
implemented a cache-to-memory checkpointing scheme to recover from CPU failures, and I leveraged
by stashing away the software failure reason, going back to the prior checkpoint, then taking some
action to prevent the code from taking the same path. If the failure occurred during an interrupt from
an I/O device, we’d simulate a device fault. If the failure occurred during a system call, we’d kill the process
that made the call. The actual yield in the field of this was small, either because each bug found yet
another way around the protection to allow a crash, or because the we ended up killing off the
primary application. When it did work, it meant that the bug itself would be ignored, rather than fixed,
until it manifested itself in a real crash.

Anyway, I’m all for a more restricted driver environment that would isolate which driver failed. However,
my enthusiasm is focused on this as a diagnosis tool, rather than as some panacea that allows buggy drivers
to be left unfixed.

-DH

PS. Peter, shouldn’t you just by a sound card with a driver that works?

----- Original Message -----
From: “Bill Christie”
To: “NT Developers Interest List”
Cc: “ntdev (E-mail)”
Sent: Wednesday, October 03, 2001 12:57 PM
Subject: [ntdev] RE: A new version of windows…

> Peter,
>
> I got my copy of the NT insider today, and I read your “pontificates”
> article with a great deal of interest. I have two thoughts on this…
>
> 1) I have always thought that there should be some “intermediate” level of
> drivers, where non-essential (yet non user-mode) code should reside. It
> always bothered me that in X86-land, only two levels of hardware protection
> were used: ring-3 and ring-0. What about rings 1 & 2? Why all-or-nothing?
> I realize that originally the common code base was meant to support
> different types of processors (MIPS, PowerPC, Alpha, X86), but that’s all
> pretty much history now (ia64 excepted), and I venture to guess that 96% of
> the installed 2000/XP platforms are/will-be X86-based anyway (why else did
> Compaq drop support for the Alpha?). Why not let the hardware share some of
> the burden as well?
>
> 2) You are absolutely right - a lot of the pseudo-driver code does need to
> be kicked out of kernel-mode space. Please understand where I’m coming
> from. I don’t write KMDs for a living. Roughly 85% of the code I write is
> user-mode. I chose the NT platform for it’s stability, not it’s speed. But
> I was forced into learning and writing KMDs because I had to support my
> company’s legacy I/O acquisition cards, cards that only needed simple port
> I/O and interrupt capability. I’ll bet there are a lot of other devices out
> there that fall into this category, the category of non-essential, yet
> hardware-driven. The pressures of market demands and company deadlines
> makes REALLY learning kernel mode drivers difficult and expensive. I’m
> willing to bet that there are very few people out there that have your level
> of expertise in device driver writing. Most people just want to be able to
> get at their hardware, and thus they learn the bare minimum to get the job
> done. Are these those kinds of device drivers you want to give free-reign,
> to put on an equal footing with the OS? I don’t think so…
>
> How many times have you seen somebody post a question like “how do I share
> memory between my user-mode app and my driver?” - chances are, the poor soul
> was just trying to talk to his simple hardware - he wasn’t trying to write a
> file-system or network driver. There really SHOULD be a sandbox for these
> types of drivers. Maybe someday there will.
>
> Writing your article was a great start toward this effort. You’ve got my
> 100% support.
>
> Regards,
>
> Bill Christie, Software Engineer
> Link Engineering Company
> 43855 Plymouth Oaks Blvd.
> Plymouth, MI 48170
> www.linkeng.com
>
>
>
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User-11 · October 5, 2001, 9:11am

I think we are in general agreement here. I fear that my original post may
have left the impression that I wished for an environment where I could be
lazy and/or careless in my development of a driver, and therefore wanted
some kind of insulating bubble that would let me code in this fashion
without without crashing the OS. This is not the case. What I was trying
to advocate was two things:

An environment that would protect critical OS functionality from errant
drivers. If the driver is errant due to malfunctioning hardware, the OS
could shut it down. If the driver is errant due to bad design/poor coding,
that’s a separate issue, (and it probably should be shut down). When that
happens, the developer would have a pretty good clue that his driver was
crap, and could fix it - BUT THE OS WOULD STILL RUN - his crappy driver
would not have the chance to corrupt core OS functionality. This is
analogous to the type of protetction that is afforded to user-mode programs.
Obviously, if the driver in question supplies core functionality, then all
bets are off. Those kinds of drivers just have to work. Period. I don’t see
how the OS can protect against problems there.
A simpler driver model for simple I/O driven hardware. I realize that’s
probably pretty unrealistic, given the complexity of SMP, security, and all
the other requirements of a modern OS. And for drivers that are supplied to
the commercial mass-market, I agree wholeheartedly with enforcing rigid
rules and models, if the end result is a stable OS. But sometimes I do pine
for the days when I could just poke the holes on my hardware and get the job
done, without having to worry about a Pnp manager, the right .INF
installation files, IRPs, spinlocks, IOmanagers, security descriptors,
DACLS, MDLs, etc. etc. etc… Sorry - I guess I’m just whining that I want
my cake and eat it too. Time to shut up now.

-bill

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dave Harvey
Sent: Friday, October 05, 2001 12:52 AM
To: NT Developers Interest List
Subject: [ntdev] RE: A new version of windows…

Anyway, I’m all for a more restricted driver environment that
would isolate which driver failed. However,
my enthusiasm is focused on this as a diagnosis tool, rather
than as some panacea that allows buggy drivers
to be left unfixed.

-DH

----- Original Message -----
From: “Bill Christie”
> To: “NT Developers Interest List”
> Cc: “ntdev (E-mail)”
> Sent: Wednesday, October 03, 2001 12:57 PM
> Subject: [ntdev] RE: A new version of windows…
>
>
> > Peter,
> >
> > I got my copy of the NT insider today, and I read your
> “pontificates”
> > article with a great deal of interest. I have two
> thoughts on this…
> >
> > 1) I have always thought that there should be some
> “intermediate” level of
> > drivers, where non-essential (yet non user-mode) code
> should reside. It
> > always bothered me that in X86-land, only two levels of
> hardware protection
> > were used: ring-3 and ring-0. What about rings 1 & 2? Why
> all-or-nothing?
> > I realize that originally the common code base was meant to support
> > different types of processors (MIPS, PowerPC, Alpha, X86),
> but that’s all
> > pretty much history now (ia64 excepted), and I venture to
> guess that 96% of
> > the installed 2000/XP platforms are/will-be X86-based
> anyway (why else did
> > Compaq drop support for the Alpha?). Why not let the
> hardware share some of
> > the burden as well?
> >
> > 2) You are absolutely right - a lot of the pseudo-driver
> code does need to
> > be kicked out of kernel-mode space. Please understand
> where I’m coming
> > from. I don’t write KMDs for a living. Roughly 85% of the
> code I write is
> > user-mode. I chose the NT platform for it’s stability, not
> it’s speed. But
> > I was forced into learning and writing KMDs because I had
> to support my
> > company’s legacy I/O acquisition cards, cards that only
> needed simple port
> > I/O and interrupt capability. I’ll bet there are a lot of
> other devices out
> > there that fall into this category, the category of
> non-essential, yet
> > hardware-driven. The pressures of market demands and
> company deadlines
> > makes REALLY learning kernel mode drivers difficult and
> expensive. I’m
> > willing to bet that there are very few people out there
> that have your level
> > of expertise in device driver writing. Most people just
> want to be able to
> > get at their hardware, and thus they learn the bare minimum
> to get the job
> > done. Are these those kinds of device drivers you want to
> give free-reign,
> > to put on an equal footing with the OS? I don’t think so…
> >
> > How many times have you seen somebody post a question like
> “how do I share
> > memory between my user-mode app and my driver?” - chances
> are, the poor soul
> > was just trying to talk to his simple hardware - he wasn’t
> trying to write a
> > file-system or network driver. There really SHOULD be a
> sandbox for these
> > types of drivers. Maybe someday there will.
> >
> > Writing your article was a great start toward this effort.
> You’ve got my
> > 100% support.
> >
> > Regards,
> >
> > Bill Christie, Software Engineer
> > Link Engineering Company
> > 43855 Plymouth Oaks Blvd.
> > Plymouth, MI 48170
> > www.linkeng.com
> >
> >
> >
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> xxxxx@syssoftsol.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@linkeng.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · October 5, 2001, 1:06pm

> 1) An environment that would protect critical OS functionality from errant

drivers. If the driver is errant due to malfunctioning hardware, the OS
could shut it down. If the driver is errant due to bad design/poor
coding,
that’s a separate issue, (and it probably should be shut down).

Without knowing something about the device, how would the O/S be able to
tell
whether a problem was the result of errant driver code or aberrant hardware
behavior? If the O/S *does* know about the device’s habits, why does it need
the
driver?

The whole purpose of a driver is to give the O/S the ability to understand a
piece
of hardware it would not otherwise recognize.

[…]

his crappy driver would not have the chance to corrupt core OS
functionality.
This is analogous to the type of protetction that is afforded to user-mode
programs.

If memory serves, some of the original “back-of-a-napkin” designs for
Windows NT called
for drivers to run in Ring 1 rather than Ring 0. The objective was exactly
what you
described – protecting core O/S components from flakey drivers. The idea
was dropped
for two reasons: (a) It would have meant no NT on RISC platforms (which
typically have only
two modes – Supervisor and User), and (b) all the mode-switching from Ring
0 to Ring 1
introduced noticeable performance degradation.

Ultimately, no amount of protection will keep you totally safe from bad
coders. I’d really
hate to see “safety” used as an excuse for yet-another drop in system
performance. The amount
of iron required to run NT/Win2K is already embarrassing…

A simpler driver model for simple I/O driven hardware.

A simpler driver model isn’t likely at this point. But what about using a
toolkit, or a good class
library, or a driver wizard to generate code for you? Doesn’t that get you
to the same place: Creating
a basic driver for a simple piece of hardware without worrying about most of
the details?

Regards,
-Art Baker

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User-11 · October 5, 2001, 4:23pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Art Baker
Sent: Friday, October 05, 2001 1:03 PM
To: NT Developers Interest List
Subject: [ntdev] RE: A new version of windows…

A simpler driver model isn’t likely at this point. But what
about using a
toolkit, or a good class
library, or a driver wizard to generate code for you? Doesn’t
that get you
to the same place: Creating
a basic driver for a simple piece of hardware without
worrying about most of
the details?

Yes, a driver wizard, class library, or good toolkit would/can do that, and
indeed there are some available now. When I started down this road, back in
'96, I don’t think there were any. Back then, it was quite a learning
curve, one not for the timid. Thankfully, I had your book to help me along.
The DDK docs (and WinDbg) have certainly come a long way since then.

If memory serves, some of the original “back-of-a-napkin” designs for
Windows NT called
for drivers to run in Ring 1 rather than Ring 0. The
objective was exactly
what you
described – protecting core O/S components from flakey
drivers. The idea
was dropped
for two reasons: (a) It would have meant no NT on RISC
platforms (which
typically have only
two modes – Supervisor and User), and (b) all the
mode-switching from Ring
0 to Ring 1
introduced noticeable performance degradation.

Back then, that was a valid argument. But now that RISC is no longer
supported, and x86 (and ia64) seems to be de-facto, perhaps a little help
from the folks at intel could make the mode-switching less expensive?.
Maybe what’s really needed is a joint design effort between the hardware and
software folks at intel and Microsoft.

I’d really hate to see “safety” used as an excuse for
yet-another drop in system performance. The amount
of iron required to run NT/Win2K is already embarrassing…

Yes, it does take a lot of horsepower to run. Much of it, I suspect, wasted
on glitzy stuff that has little to do with system stability, and more to do
with flash and sex appeal. But hey, stability doesn’t sell, glitz does.
And Microsoft does a better job at selling this stuff than anybody else.

Regards,
-bill

> 1) An environment that would protect critical OS
functionality from errant
> drivers. If the driver is errant due to malfunctioning
hardware, the OS
> could shut it down. If the driver is errant due to bad design/poor
coding,
> that’s a separate issue, (and it probably should be shut down).

Without knowing something about the device, how would the O/S
be able to
tell
whether a problem was the result of errant driver code or
aberrant hardware
behavior? If the O/S *does* know about the device’s habits,
why does it need
the
driver?

The whole purpose of a driver is to give the O/S the ability
to understand a
piece
of hardware it would not otherwise recognize.

[…]
> his crappy driver would not have the chance to corrupt core OS
functionality.
> This is analogous to the type of protetction that is
afforded to user-mode
programs.

If memory serves, some of the original “back-of-a-napkin” designs for
Windows NT called
for drivers to run in Ring 1 rather than Ring 0. The
objective was exactly
what you
described – protecting core O/S components from flakey
drivers. The idea
was dropped
for two reasons: (a) It would have meant no NT on RISC
platforms (which
typically have only
two modes – Supervisor and User), and (b) all the
mode-switching from Ring
0 to Ring 1
introduced noticeable performance degradation.

Ultimately, no amount of protection will keep you totally
safe from bad
coders. I’d really
hate to see “safety” used as an excuse for yet-another drop in system
performance. The amount
of iron required to run NT/Win2K is already embarrassing…

> 2) A simpler driver model for simple I/O driven hardware.

A simpler driver model isn’t likely at this point. But what
about using a
toolkit, or a good class
library, or a driver wizard to generate code for you? Doesn’t
that get you
to the same place: Creating
a basic driver for a simple piece of hardware without
worrying about most of
the details?

Regards,
-Art Baker

You are currently subscribed to ntdev as: xxxxx@linkeng.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · October 5, 2001, 5:11pm

> Anyway, I’m all for a more restricted driver environment that would isolate which driver

failed.

IIRC IBM360 mainframes had these fault-tolerance features - the machine continues to run after hardware failures, just in degraded
form.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · October 5, 2001, 5:11pm

> crap, and could fix it - BUT THE OS WOULD STILL RUN - his crappy driver

would not have the chance to corrupt core OS functionality. This is

Possible and seriously studied in late 80ies - early 90ies, but at the cost of performance, so, the modern mass-market OSes are not
such.
The market-supported opinion is that you can achieve the necessary level of stability even without such protection, so no need to
sacrifice performance on it.

for the days when I could just poke the holes on my hardware and get the job
done, without having to worry about a Pnp manager,

That is what port/miniport model is for.
After all - your driver must at least reserve your ports in the OS’s arbiter to avoid their allocation for other hardware.

the right .INF installation files

Copy/paste the existing one with slight edits.

, IRPs

Sorry, if you want to do IO - then this is the way.

, spinlocks

You want your code to run on SMP?
Again - the port/miniport model sometimes frees you from this burden.

, IOmanagers, security descriptors,
DACLS

The majority of drivers have no use of those.

, MDLs

You want to run DMA on a virtual-memory OS? Then MDLs - regadless of their name in the particular OS implementation - are necessary.

After all:

if your app wants to poke to hardware ports, what about other apps wanting to do the same? What about “smart” programmers who want
to poke to ATA ports already governed by ATA driver?
What about people who will have the temptation to write, say, a soundcard driver in user mode?
Such kind of third-party software will degrade the OS stability to the level below the one smaller Windows have.
After this the UNIX fans (yes, UNIX has no such holes, yes, they have no intention at all to make life easier for a system- or
hardware-level developer ) will proudly say “Microsoft sux” after this

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com