Hooking Interrupts

Guys,

I want to write an example driver that hooks an interrupt, but I’m having a
problem doing it in a well behaved way. I don’t want to do it in the WDM
way, it’s too complicated for a beginner. But the old HalGetInterruptVector
way is no longer documented in the DDK - my students are having problems
finding good documentation. I’m a machine level guy and I feel tempted to
just go and frig the IDT by hand, but I would like to teach them some DDK
techniques. So, here’s the question: if I want, say, to hook a timer
interrupt with my own ISR/DPC pair, in a way that’s blessed at least by the
“legacy” DDK Driver way, what are my choices ? Inquiring minds want to know.
:slight_smile:

Alberto.

-----Original Message-----
From: xxxxx@thermonicolet.com [mailto:xxxxx@thermonicolet.com]
Sent: Tuesday, March 12, 2002 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: usb vendor specific request

No - not without a driver in the USB stack. However, building a driver that
attaches to the stack is not that hard and (as the other poster pointer out)
then you can simply expose an IOCTL that can be called from user mode with
the vendor request descriptor as its data.

  • Dennis

Dennis Merrill
Embedded Systems Engineer
Thermo Electron Corporation
Spectroscopy Division

-----Original Message-----
From: Fareed Anwar [ mailto:xxxxx@hotmail.com
mailto:xxxxx ]
Sent: Monday, March 11, 2002 2:46 PM
To: NT Developers Interest List
Subject: [ntdev] usb vendor specific request

Hi!

Is there a way we can send usb vendor specific requests to a device from
user-mode applications or from a driver which is not in the usb driver
stack.

Thanks

Fareed

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
http:


You are currently subscribed to ntdev as: xxxxx@thermonicolet.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%</http:></mailto:xxxxx>

Well, first let me say that I don’t know the answer to your question, a=
nd
then immediately follow by commending you for choosing not to teach a b=
unch
of students to flagrantly disregard the fact that other drivers have to=

work with yours, and it’s better to do things in ways that promote
interoperability, rather than the alternative of hacking it in risky an=
d
stability compromising ways.

Phil

“Moreira, Alberto” @lists.osr.com on
03/12/2002 08:59:34 AM

Please respond to “NT Developers Interest List”

Sent by: xxxxx@lists.osr.com

To: “NT Developers Interest List”
cc:

Subject: [ntdev] Hooking Interrupts

Guys,

I want to write an example driver that hooks an interrupt, but I’m hav=
ing
a problem doing it in a well behaved way. I don’t want to do it in the=
WDM
way, it’s too complicated for a beginner. But the old
HalGetInterruptVector way is no longer documented in the DDK - my stud=
ents
are having problems finding good documentation. I’m a machine level gu=
y
and I feel tempted to just go and frig the IDT by hand, but I would li=
ke
to teach them some DDK techniques. So, here’s the question: if I want,=

say, to hook a timer interrupt with my own ISR/DPC pair, in a way that=
's
blessed at least by the “legacy” DDK Driver way, what are my choices ?=

Inquiring minds want to know. :slight_smile:

Alberto.

-----Original Message-----
From: xxxxx@thermonicolet.com [mailto:xxxxx@thermonicolet.com]
Sent: Tuesday, March 12, 2002 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: usb vendor specific request

No - not without a driver in the USB stack.=A0 However, building a dri=
ver
that attaches to the stack is not that hard and (as the other poster
pointer out) then you can simply expose an IOCTL that can be called fr=
om
user mode with the vendor request descriptor as its data.

- Dennis

Dennis Merrill
Embedded Systems Engineer
Thermo Electron Corporation
Spectroscopy Division

-----Original Message-----
From: Fareed Anwar [mailto:xxxxx@hotmail.com]
Sent: Monday, March 11, 2002 2:46 PM
To: NT Developers Interest List
Subject: [ntdev] usb vendor specific request

Hi!

Is there a way we can send usb vendor specific requests to a device fr=
om
user-mode applications or from a driver which is not in the usb driver=

stack.

Thanks

Fareed

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


You are currently subscribed to ntdev as: xxxxx@thermonicolet.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@compuware.co=
m
To unsubscribe send a blank email to %%email.unsub%% —
You are currently subscribed to ntdev as: xxxxx@seagate.com
To unsubscribe send a blank email to %%email.unsub%%

=

Well…

If hooking interrupts by hand was that damaging an idea, our SoftICE and
BoundsChecker would be a lot less robust and stable than what they are
today. Do it right, and everything keeps working, but doing it right doesn’t
necessarily mean doing it by the book. But I want to teach them how to do it
by the book ! Even though sometimes I wonder whether the way of the book
qualifies as “doing it right”.

Alberto.

-----Original Message-----
From: xxxxx@seagate.com [mailto:xxxxx@seagate.com]
Sent: Tuesday, March 12, 2002 11:11 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Hooking Interrupts

Well, first let me say that I don’t know the answer to your question, and
then immediately follow by commending you for choosing not to teach a bunch
of students to flagrantly disregard the fact that other drivers have to
work with yours, and it’s better to do things in ways that promote
interoperability, rather than the alternative of hacking it in risky and
stability compromising ways.

Phil

“Moreira, Alberto” @lists.osr.com on
03/12/2002 08:59:34 AM

Please respond to “NT Developers Interest List”

Sent by: xxxxx@lists.osr.com

To: “NT Developers Interest List”
cc:

Subject: [ntdev] Hooking Interrupts

Guys,

I want to write an example driver that hooks an interrupt, but I’m having
a problem doing it in a well behaved way. I don’t want to do it in the WDM
way, it’s too complicated for a beginner. But the old
HalGetInterruptVector way is no longer documented in the DDK - my students
are having problems finding good documentation. I’m a machine level guy
and I feel tempted to just go and frig the IDT by hand, but I would like
to teach them some DDK techniques. So, here’s the question: if I want,
say, to hook a timer interrupt with my own ISR/DPC pair, in a way that’s
blessed at least by the “legacy” DDK Driver way, what are my choices ?
Inquiring minds want to know. :slight_smile:

Alberto.

-----Original Message-----
From: xxxxx@thermonicolet.com [mailto:xxxxx@thermonicolet.com]
Sent: Tuesday, March 12, 2002 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: usb vendor specific request

No - not without a driver in the USB stack.? However, building a driver
that attaches to the stack is not that hard and (as the other poster
pointer out) then you can simply expose an IOCTL that can be called from
user mode with the vendor request descriptor as its data.

- Dennis

Dennis Merrill
Embedded Systems Engineer
Thermo Electron Corporation
Spectroscopy Division

-----Original Message-----
From: Fareed Anwar [mailto:xxxxx@hotmail.com]
Sent: Monday, March 11, 2002 2:46 PM
To: NT Developers Interest List
Subject: [ntdev] usb vendor specific request

Hi!

Is there a way we can send usb vendor specific requests to a device from
user-mode applications or from a driver which is not in the usb driver
stack.

Thanks

Fareed

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


You are currently subscribed to ntdev as: xxxxx@thermonicolet.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%% —
You are currently subscribed to ntdev as: xxxxx@seagate.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

There is no way ‘blessed’ in either the pre-w2k or post w2k ddk to ‘hook’
any interrupts, other than the wdm and legacy mechanisms for associating
driver ISR routines with device interrupt vectors, documented in the w2k and
xp ddk (and samples.) You don’t ‘hook timer interrupts’ in nt, you register
for timer dpc callbacks.

FYI HalGetInterruptVector is documented in the xp ddk, it is simply marked
as obsolete:

ULONG
HalGetInterruptVector(
IN INTERFACE_TYPE InterfaceType,
IN ULONG BusNumber,
IN ULONG BusInterruptLevel,
IN ULONG BusInterruptVector,
OUT PKIRQL Irql,
OUT PKAFFINITY Affinity
);

I rather doubt that the timer interrupt vector is described as shareable in
NT, thus making it difficult for you to legitimately connect your isr to
this vector.

That’s my problem, the assumption that hooking an interrupt routine is not a
valid kernel level operation. What I want to achieve is, in the end, a
driver iocontrol routine that takes an ISR and a vector and hooks that
vector with that ISR - no questions asked, and no presuposition of an actual
device existing behind that hook. I know that you can kick a DPC with a
timer, but that’s not what I want - I want to kick an ISR with a timer. It
needn’t be a timer, mind you, but timer interrupts happen, so, they’re an
easy target - other interrupts have to be generated, and that makes things
not as easy to handle.

Also, hooking can be done irrelevant of whether the interrupt is shareable:
hooking is a software level action at the OS level. I may want to hook an
interrupt, for example, for performance monitoring purposes, or for
debugging, even if that particular interrupt line is not shareable. For
example, take the bpint command in SoftICE, is there a way to implement it
without resorting to brute force ?

Alberto.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Tuesday, March 12, 2002 11:31 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Hooking Interrupts

There is no way ‘blessed’ in either the pre-w2k or post w2k ddk to ‘hook’
any interrupts, other than the wdm and legacy mechanisms for associating
driver ISR routines with device interrupt vectors, documented in the w2k and
xp ddk (and samples.) You don’t ‘hook timer interrupts’ in nt, you register
for timer dpc callbacks.

FYI HalGetInterruptVector is documented in the xp ddk, it is simply marked
as obsolete:

ULONG
HalGetInterruptVector(
IN INTERFACE_TYPE InterfaceType,
IN ULONG BusNumber,
IN ULONG BusInterruptLevel,
IN ULONG BusInterruptVector,
OUT PKIRQL Irql,
OUT PKAFFINITY Affinity
);

I rather doubt that the timer interrupt vector is described as shareable in
NT, thus making it difficult for you to legitimately connect your isr to
this vector.


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

I’m having deja vue all over again. We’ve discussed this to death. What
Numega does to insert a third party kernel debugger into NT is interesting
but it is not an example of good programming practice for commercial quality
general use device drivers. And if I’m not mistaken, your software comes
with all sorts of disclaimers about how it should not be used in a
production environment, right?

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, March 12, 2002 11:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Hooking Interrupts

Well…

If hooking interrupts by hand was that damaging an idea, our
SoftICE and BoundsChecker would be a lot less robust and
stable than what they are today. Do it right, and everything
keeps working, but doing it right doesn’t necessarily mean
doing it by the book. But I want to teach them how to do it
by the book ! Even though sometimes I wonder whether the way
of the book qualifies as “doing it right”.

Alberto.

RE: [ntdev] usb vendor specific requestAlberto,

Use the NT 4 DDK to build the driver. I have no problems in running an NT4 driver under XP. Your next problem might be overcoming hooking the timer interrupt if it is not shareable, which means you might choose another IRQ.

:slight_smile: and Kudos to you for not taking the “My way is better …” :slight_smile:


Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net

“Moreira, Alberto” wrote in message news:xxxxx@ntdev…
Guys,

I want to write an example driver that hooks an interrupt, but I’m having a problem doing it in a well behaved way. I don’t want to do it in the WDM way, it’s too complicated for a beginner. But the old HalGetInterruptVector way is no longer documented in the DDK - my students are having problems finding good documentation. I’m a machine level guy and I feel tempted to just go and frig the IDT by hand, but I would like to teach them some DDK techniques. So, here’s the question: if I want, say, to hook a timer interrupt with my own ISR/DPC pair, in a way that’s blessed at least by the “legacy” DDK Driver way, what are my choices ? Inquiring minds want to know. :slight_smile:

Alberto.

Bounds Checker et. al. are not normal production code. They run on systems
that a crash has little real impact. These are never meant to run in
production systems. Bad example.

Greg

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Tuesday, March 12, 2002 10:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Hooking Interrupts

Well…

If hooking interrupts by hand was that damaging an idea, our SoftICE and
BoundsChecker would be a lot less robust and stable than what they are
today. Do it right, and everything keeps working, but doing it right doesn’t
necessarily mean doing it by the book. But I want to teach them how to do it
by the book ! Even though sometimes I wonder whether the way of the book
qualifies as “doing it right”.

Alberto.

-----Original Message-----
From: xxxxx@seagate.com [mailto:xxxxx@seagate.com]
Sent: Tuesday, March 12, 2002 11:11 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Hooking Interrupts

Well, first let me say that I don’t know the answer to your question, and
then immediately follow by commending you for choosing not to teach a bunch
of students to flagrantly disregard the fact that other drivers have to
work with yours, and it’s better to do things in ways that promote
interoperability, rather than the alternative of hacking it in risky and
stability compromising ways.

Phil

“Moreira, Alberto” @lists.osr.com on
03/12/2002 08:59:34 AM

Please respond to “NT Developers Interest List”

Sent by: xxxxx@lists.osr.com

To: “NT Developers Interest List”
cc:

Subject: [ntdev] Hooking Interrupts

Guys,

I want to write an example driver that hooks an interrupt, but I’m having
a problem doing it in a well behaved way. I don’t want to do it in the WDM
way, it’s too complicated for a beginner. But the old
HalGetInterruptVector way is no longer documented in the DDK - my students
are having problems finding good documentation. I’m a machine level guy
and I feel tempted to just go and frig the IDT by hand, but I would like
to teach them some DDK techniques. So, here’s the question: if I want,
say, to hook a timer interrupt with my own ISR/DPC pair, in a way that’s
blessed at least by the “legacy” DDK Driver way, what are my choices ?
Inquiring minds want to know. :slight_smile:

Alberto.

-----Original Message-----
From: xxxxx@thermonicolet.com [mailto:xxxxx@thermonicolet.com]
Sent: Tuesday, March 12, 2002 10:33 AM
To: NT Developers Interest List
Subject: [ntdev] RE: usb vendor specific request

No - not without a driver in the USB stack. However, building a driver
that attaches to the stack is not that hard and (as the other poster
pointer out) then you can simply expose an IOCTL that can be called from
user mode with the vendor request descriptor as its data.

- Dennis

Dennis Merrill
Embedded Systems Engineer
Thermo Electron Corporation
Spectroscopy Division

-----Original Message-----
From: Fareed Anwar [mailto:xxxxx@hotmail.com]
Sent: Monday, March 11, 2002 2:46 PM
To: NT Developers Interest List
Subject: [ntdev] usb vendor specific request

Hi!

Is there a way we can send usb vendor specific requests to a device from
user-mode applications or from a driver which is not in the usb driver
stack.

Thanks

Fareed

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


You are currently subscribed to ntdev as: xxxxx@thermonicolet.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%% —
You are currently subscribed to ntdev as: xxxxx@seagate.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to %%email.unsub%%

Mark, I’m not teaching commercial grade device driver programming, I’m
teaching operating systems techniques. I’m using drivers here in the way
Linux uses kernel modules, that is, as a ‘foot in the door’ thing to reach
into the parts other software cannot reach.

And it depends on what you call “production” environment. We routinely use
the combination of SoftICE and BoundsChecker to unearth hard-to-find
production time bugs, for example, that intermittent BSOD by the sixth hour
of running the WHQL stress test overnight. Also, TrueTime does hook too, and
it’s a runtime production level performance tool.

There’s more to kernel programming than writing production grade drivers !

Alberto.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Tuesday, March 12, 2002 11:40 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Hooking Interrupts

I’m having deja vue all over again. We’ve discussed this to death. What
Numega does to insert a third party kernel debugger into NT is interesting
but it is not an example of good programming practice for commercial quality
general use device drivers. And if I’m not mistaken, your software comes
with all sorts of disclaimers about how it should not be used in a
production environment, right?

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, March 12, 2002 11:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Hooking Interrupts

Well…

If hooking interrupts by hand was that damaging an idea, our
SoftICE and BoundsChecker would be a lot less robust and
stable than what they are today. Do it right, and everything
keeps working, but doing it right doesn’t necessarily mean
doing it by the book. But I want to teach them how to do it
by the book ! Even though sometimes I wonder whether the way
of the book qualifies as “doing it right”.

Alberto.


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

I hear you. I was trying to avoid having to wire my own dongle into the
parallel port to generate interrupts. :slight_smile:

Alberto.

-----Original Message-----
From: Gary G. Little [mailto:xxxxx@broadstor.com]
Sent: Tuesday, March 12, 2002 11:42 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Hooking Interrupts

Alberto,

Use the NT 4 DDK to build the driver. I have no problems in running an NT4
driver under XP. Your next problem might be overcoming hooking the timer
interrupt if it is not shareable, which means you might choose another IRQ.

:slight_smile: and Kudos to you for not taking the “My way is better …” :slight_smile:


Gary G. Little
xxxxx@broadstor.com mailto:xxxxx
xxxxx@inland.net mailto:xxxxx

“Moreira, Alberto” < xxxxx@compuware.com
mailto:xxxxx > wrote in message news:xxxxx@ntdev
news:xxxxx

Guys,

I want to write an example driver that hooks an interrupt, but I’m having a
problem doing it in a well behaved way. I don’t want to do it in the WDM
way, it’s too complicated for a beginner. But the old HalGetInterruptVector
way is no longer documented in the DDK - my students are having problems
finding good documentation. I’m a machine level guy and I feel tempted to
just go and frig the IDT by hand, but I would like to teach them some DDK
techniques. So, here’s the question: if I want, say, to hook a timer
interrupt with my own ISR/DPC pair, in a way that’s blessed at least by the
“legacy” DDK Driver way, what are my choices ? Inquiring minds want to know.
:slight_smile:

Alberto.




You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%</news:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Then I’ve got an idea: use linux, it is a highly unstructured mess where you
and anyone else can do anything you want.

So are you saying that your softice and boundschecker kernel components do
NOT come with a disclaimer regarding use in a production environment?

Sorry, Alberto, that’s a straw man. Debugging tools have a very different
purpose than a generic driver. A debugger is intended to be used in a
controlled situation, where crashes are almost expected anyways (I’m not
saying a debugger should crash). But a generic driver is intended to be
used by everybody, everywhere, including mission critical systems. If you
don’t play nice in those situations, you blow up.

Let’s face it, development tools have different requirements, and SoftICE
and BoundsChecker fall into that category.

Disclaimer: I am a user of SoftICE.

Scott

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…

>Well…

>If hooking interrupts by hand was that damaging an idea, our SoftICE and
>BoundsChecker would be a lot less robust and stable than what they are
>today.

I don’t buy that following the “rules” gives anyone any more stability, and
you know what, neither SoftICE nor BoundsChecker crash nearly as much as
some pieces of production code I’ve had contact with. And no, not every
driver, even production level, is intended to work on mission critical
systems: building a mission-critical driver for a wordly PC home application
or even for a business application is, as I see, a gross case of
overengineering. I don’t expect my debugger to crash any more than I expect
my driver to crash, production or no production.

Alberto.

-----Original Message-----
From: Scott Neugroschl [mailto:xxxxx@troikanetworks.com]
Sent: Tuesday, March 12, 2002 4:49 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Hooking Interrupts

Sorry, Alberto, that’s a straw man. Debugging tools have a very different
purpose than a generic driver. A debugger is intended to be used in a
controlled situation, where crashes are almost expected anyways (I’m not
saying a debugger should crash). But a generic driver is intended to be
used by everybody, everywhere, including mission critical systems. If you
don’t play nice in those situations, you blow up.

Let’s face it, development tools have different requirements, and SoftICE
and BoundsChecker fall into that category.

Disclaimer: I am a user of SoftICE.

Scott

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…

>Well…

>If hooking interrupts by hand was that damaging an idea, our SoftICE and
>BoundsChecker would be a lot less robust and stable than what they are
>today.


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

>>building a mission-critical driver for a wordly PC home application

>or even for a business application is, as I see, a gross case of
>overengineering.

Why is it that my data and my time are significantly less important to you when I’m at home than when I’m at work?

Why is it acceptable for my home pc to crash due to a driver bug, and not for my work desktop to crash due to the same driver bug?

I find this attitude unacceptable. Anything that presumes that my time is unimportant to me is simply unacceptable.

> ----------

From: xxxxx@spinnakernet.com[SMTP:xxxxx@spinnakernet.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, March 13, 2002 1:15 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Hooking Interrupts

>>building a mission-critical driver for a wordly PC home application
>>or even for a business application is, as I see, a gross case of
>>overengineering.

Why is it that my data and my time are significantly less important to you
when I’m at home than when I’m at work?

Why is it acceptable for my home pc to crash due to a driver bug, and not
for my work desktop to crash due to the same driver bug?

I find this attitude unacceptable. Anything that presumes that my time is
unimportant to me is simply unacceptable.

It is not unimportant but not so much important as mission critical task. I
see a difference. It is about time and money; do you really want to pay for
mission critical drivers + OS (so why use XP?) ?

As usual, only few attempts to answer original question and many kind or
not-so-kind attempts to forbid even trying. Haven’t we had this discussion
many times ago? Alberto clearly expressed the purpose: teach OS techniques.
Good teaching means understanding and for understanding it is necessary to
show how things work. To show it is sometimes necessary to use non-standard
techniques. It doesn’t mean students should use these techniques in their
drivers (if any), but they can use them for testing or debugging purposes.

Actually, SoftICE is less stable than other drivers. It crashes when 16-bit
setup is run on XP, when I created 6000 threads for some stupid reason and
once per month just freeze which I’m not able to reproduce. Still it is
stable enough so I dare keep it running even if browse web pages, write
mails or do any other important work.

Sorry for adding next noise to this thread. The other possibility was
working.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

>

As usual, only few attempts to answer original question and
many kind or not-so-kind attempts to forbid even trying.
Haven’t we had this discussion many times ago? Alberto
clearly expressed the purpose: teach OS techniques. Good
teaching means understanding and for understanding it is
necessary to show how things work. To show it is sometimes
necessary to use non-standard techniques. It doesn’t mean
students should use these techniques in their drivers (if
any), but they can use them for testing or debugging purposes.

I’m sorry, but what Alberto said originally was “I want to write an
example driver that hooks an interrupt, but I’m having a problem doing
it in a well behaved way.” He can’t, as there is no ‘well behaved way’
to ‘hook an interrupt’ in NT, (nor in my opinion should there be.) Hack
away Alberto, teach your students how to hack hastily in the OS too, but
if you ask how to cut corners without cutting corners I will note that
your request is absurd.

=====================
Mark Roddy
Windows XP/2000/NT Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
xxxxx@hollistech.com
For Windows Device Driver Training: see www.azius.com

>I don’t buy that following the “rules” gives >anyone any more stability,

Well, just because you don’t buy it…

and
you know what, neither SoftICE nor BoundsChecker >crash nearly as much as
some pieces of production code I’ve had contact >with.

That is great lets all go with the “We are no worse than anybody else”
approach.

And no, not every
driver, even production level, is intended to >work on mission critical
systems: building a mission-critical driver for >a wordly PC home
application
or even for a business application is, as I see, >a gross case of
overengineering. I don’t expect my debugger to >crash any more than I
expect
my driver to crash, production or no production.

Alberto.

I would say you ought not be writing commercial production drivers then,
which you aren’t, so we are okay. This is the totally wrong approach.
The whole push of the industry has been to push server class features and
stability to the home PC and OS. Ask any user of a home PC what
frustrates them most, and you will hear something about “the stupid
machine crashes all the time”, everytime. Not to mention the lines
between server and home PC are getting blurrier every day. So, I don’t
know how you could know what type of system your production driver will go
into in most cases.

All in all, what I think is wrong here, and take my opinions for what they
are worth, is you are using the wrong tool for the job. You are trying to
teach basic operating system behavior with an extremely advanced OS. You
would be much better off using Linux, or CE, or maybe a multi-threaded
RTOS to teach fundamental operating system behavior. With these platforms
you can ‘own the world’. Anyway, NT and its derivatives are not first
semester OSes :slight_smile:

Bill McKenzie

On Tue, 12 Mar 2002, Moreira, Alberto wrote:

And no, not every
driver, even production level, is intended to work on mission critical
systems: building a mission-critical driver for a wordly PC home application
or even for a business application is, as I see, a gross case of
overengineering.
It is fortunate that you don’t write anything that unsuspecting computer
users might have to install.

Everyone deserves a stable computer. It doesn’t matter what they’re
doing. Downtime from hardware failures is tolerable, downtime from
software failures is not.


Peter xxxxx@inkvine.fluff.org
http://www.inkvine.fluff.org/~peter/

logic kicks ass:
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
legs for a horse.
(4) But the only number that is both odd and even is infinity.
(5) Therefore, horses must have an infinite number of legs.

----- Original Message -----
On Wednesday, March 13, 2002 6:52 AM “Bill McKenzie” wrote:

All in all, what I think is wrong here (…) is you are using
the wrong tool for the job. You are trying to teach basic
operating system behavior with an extremely advanced OS.
You would be much better off using Linux, or CE, or maybe a
multi-threaded RTOS to teach fundamental operating system
behavior. With these platforms you can ‘own the world’.
Anyway, NT and its derivatives are not first semester OSes :slight_smile:

In my humble opinion, may I please note that Bill made a point here?
Maybe the whole thing is just about using the right tool for the
right audience. Sure, there will be students with an high-level of
perception and understanding of the concepts; but using NT/2K and
km drivers without the base knowledge would be like starting to
build a house by the roof, with everything else missing.

(A dumb question: why not use plain-old-silly DOS and ask them
to write a TSR? That would be fairly easy and certainly would
allow them to hook timer (&other) interrupts… :slight_smile:

OTH, if Alberto’s pupils were “advanced” students (with a deep
knowledge of os concepts), willing to “get their hands on”
something more substancial, then I don’t see why they shouldn’t
learn how to get the job done (even if it is not “by the book”;
I respect all opinions on this subject, but hey - if the man wants
to do it that way, he may have his own motives, right?!..).

Just my 2 cents [(c) Someone else here in the list] here…

Miguel Monteiro
xxxxx@criticalsoftware.com

Critical Software, S.A. - http://www.criticalsoftware.com
111 North Market Street, 6th floor, San Jose, CA, USA, 95113
Tel: +1.408.9711231, Fax +1.408.9383929
R. Pedro Nunes, IPN, 3030-199 Coimbra, Portugal
Tel: +351.239.700945 - Fax: +351.239.700905

DISCLAIMER: This mail contents represent
my own personal opinions and do not, in any way,
represent the opinion or policy of Critical Software, S.A.

“Humour and love are God’s answers
to Human weaknesses” =:o)8

Ladies and Gentleman,
We have not only beat this horse to death and kept beating a dead
horse, we have dug up the corps and started beating again! As strong as my
views are on this matter, it’s time to end it. We are going to all have to
agree to respectfully disagree. I only wish we could force software
suppliers to provide warning labels on their software that lets the consumer
know they haven’t followed the guidelines issued by the OS manufacturer. As
much as I hate lawsuits, I see them as the only way to force software
suppliers to stop these insane practices.

OK, let’s drop this endless debate and get the S/N (Signal to Noise) ratio
back up above background now.

Greg