Training Question

Hi all,

I’m new to the kernel. I’ve been writing user mode stuff for about 8
years and I’m looking to add to my skill set and have a bit of
fun/challenge as well. I’ve consulted the resources mentioned in the
OSR Online FAQs, including Oney’s book. I’ve been able to set up
debugging and write some test code. As pleased as I am with that
start, that’s not real driver programming. What I’d like to do is pick
up some devices (or use some non-critical existing ones) and actually
write some real, functional drivers. Is there any simple hardware out
there for which I would have access to sufficient specifications to do
this? If so, what kinds of devices should I start with? If this is
not possible, what would you recommend that I do to make some progress
in this new territory?

TIA for any help.


Steve Johnson

The first thing I’d say is that many (perhaps the majority) of useful
drivers don’t actually touch the hardware themselves, they merely “add
value” or, in some cases, subtract it. They delegate the “real work” of
handling the hardware to the lowest level driver in the stack. Time was when
many drivers were monolithic: At one end the user, at the other the bare
iron. These days it’s a more layered affair.

You are using a dedicated test machine that isn’t your development machine,
right? You don’t care if one minute it’s working fine, the next it’s dead
and you might have to reinstall everything. Don’t do this sort of thing on
any machine that you have an immediate use for, or which contains data you
can’t recover/replace.

So, to start with I’d suggest a simple filter driver over a device you don’t
really care about: the mouse comes to mind. Stick a filter over it that does
nothing. Add a control interface that returns statistics. Once you have
something like that working, play with it - add an Ioctl that swaps left and
right buttons. Add another that reverses the direction of movement or
rotates it. Stop it working altogether. Disable double clicks. Whatever.

When you’ve got comfortable with the environment, then start touching actual
hardware: maybe buy a cheap sound card and see if you can replace one, or
more, of the drivers for it.

Where to start looking for an example to modify? The toaster stuff is where
a lot of people start. If you do choose the mouse as your first target,
there may be some better examples in the DDK than the toaster, I haven’t
been near the mouse stuff in ages (NT3.5), so my recollection is almost
certainly out of date.

Don

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Johnson
Sent: 26 January 2005 23:56
To: Windows System Software Devs Interest List
Subject: [ntdev] Training Question

Hi all,

I’m new to the kernel. I’ve been writing user mode stuff for
about 8 years and I’m looking to add to my skill set and have
a bit of fun/challenge as well. I’ve consulted the resources
mentioned in the OSR Online FAQs, including Oney’s book.
I’ve been able to set up debugging and write some test code.
As pleased as I am with that start, that’s not real driver
programming. What I’d like to do is pick up some devices (or
use some non-critical existing ones) and actually write some
real, functional drivers. Is there any simple hardware out
there for which I would have access to sufficient
specifications to do this? If so, what kinds of devices
should I start with? If this is not possible, what would you
recommend that I do to make some progress in this new territory?

TIA for any help.


Steve Johnson


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

If you want to pursue the mouse angle, you have moufiltr in the ddk to
base your driver on. BUT, it is considered a secure device, so you if
you want to talk to your filter, you need to create a 2ndary control
device object so that you can talk to it.

For more info for how to do that
http://support.microsoft.com/default.aspx?scid=kb;en-us;262305

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward
Sent: Wednesday, January 26, 2005 5:19 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Training Question

The first thing I’d say is that many (perhaps the majority) of useful
drivers don’t actually touch the hardware themselves, they merely “add
value” or, in some cases, subtract it. They delegate the “real work” of
handling the hardware to the lowest level driver in the stack. Time was
when
many drivers were monolithic: At one end the user, at the other the bare
iron. These days it’s a more layered affair.

You are using a dedicated test machine that isn’t your development
machine,
right? You don’t care if one minute it’s working fine, the next it’s
dead
and you might have to reinstall everything. Don’t do this sort of thing
on
any machine that you have an immediate use for, or which contains data
you
can’t recover/replace.

So, to start with I’d suggest a simple filter driver over a device you
don’t
really care about: the mouse comes to mind. Stick a filter over it that
does
nothing. Add a control interface that returns statistics. Once you have
something like that working, play with it - add an Ioctl that swaps left
and
right buttons. Add another that reverses the direction of movement or
rotates it. Stop it working altogether. Disable double clicks. Whatever.

When you’ve got comfortable with the environment, then start touching
actual
hardware: maybe buy a cheap sound card and see if you can replace one,
or
more, of the drivers for it.

Where to start looking for an example to modify? The toaster stuff is
where
a lot of people start. If you do choose the mouse as your first target,
there may be some better examples in the DDK than the toaster, I haven’t
been near the mouse stuff in ages (NT3.5), so my recollection is almost
certainly out of date.

Don

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Johnson
Sent: 26 January 2005 23:56
To: Windows System Software Devs Interest List
Subject: [ntdev] Training Question

Hi all,

I’m new to the kernel. I’ve been writing user mode stuff for
about 8 years and I’m looking to add to my skill set and have
a bit of fun/challenge as well. I’ve consulted the resources
mentioned in the OSR Online FAQs, including Oney’s book.
I’ve been able to set up debugging and write some test code.
As pleased as I am with that start, that’s not real driver
programming. What I’d like to do is pick up some devices (or
use some non-critical existing ones) and actually write some
real, functional drivers. Is there any simple hardware out
there for which I would have access to sufficient
specifications to do this? If so, what kinds of devices
should I start with? If this is not possible, what would you
recommend that I do to make some progress in this new territory?

TIA for any help.


Steve Johnson


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Don Ward wrote:

So, to start with I’d suggest a simple filter driver over a device you don’t
really care about: the mouse comes to mind. Stick a filter over it that does
nothing. Add a control interface that returns statistics. Once you have
something like that working, play with it - add an Ioctl that swaps left and
right buttons. Add another that reverses the direction of movement or
rotates it. Stop it working altogether. Disable double clicks. Whatever.

Though the REST of Don’s recommendations are indeed excellent, I’d
suggest the Mouse is a particularly bad place to start.

If you’re “lucky” enough to have a test system with a floppy, THAT makes
a particularly good device for you to filter. In fact, this is one of
the very first exercises that we do in our WDM driver lab class.

It might be interesting to you to keep an eye out for some actual
hardware to write an example driver for. It’s hard to find such
hardware… It’s usually expensive, poorly documented, complicated, and
not very interesting overall.

To meet the need for hardware for use in learning how to write drivers,
we’re in the process of putting together a series of devices
specifically for this purpose. These will be available for purchase
from our web site. Some of these device we’ve designed/manfactured
ourselves, others we’ve worked special agreements out with the
manufacturer. ALL of them do things that have an interactive component
to them (they have lights to light, switches to switch, etc), and will
be sold to the community AT OUR COST (typically, less than $100), and
will come with example drivers. Look for the OSR designed USB device to
be available within the next week or so for $74.

Peter
OSR

Thanks, all, for your input. That’ll give me a start.

I’ll be anxiously awaiting the availability of OSR’s training devices.


Steve Johnson

I chose the mouse because I figured the OP could do without it and it gave
him easy visual feedback on the effects of his tweaks. We all remember the
keyboard shortcuts don’t we?

However (as I said in my original post) it’s been years since I was anywhere
near the mouse stack, so if it’s got more complicated, perhaps there are
simpler places to start.

If you do aim at the floppy, make sure you have a completely separate update
path for the driver that fixes the mistake you just made that disabled the
floppy. I.e make sure you can update your driver from a USB disk or over the
network.

Also, if you possibly can, make the system partition FAT. If your system
blue screens at start up, you can sometimes get out of jail by replacing the
driver.sys file with a corrected one using a DOS boot floppy to access the
disk. Yes, there are other ways to do it, but this way is one of the
easiest.

Personally, I don’t bother to do this any more (Because my drivers never
blue screen at start up: well, almost never). But for a novice it might
happen a bit more often. I suppose I ought to check if it’s still possible
to use a FAT system partition but I suspect someone will tell me pretty
quickly if it isn’t.

Don

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter
Viscarola (OSR)
Sent: 27 January 2005 15:13
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Training Question

Don Ward wrote:
> So, to start with I’d suggest a simple filter driver over a
device you
> don’t really care about: the mouse comes to mind. Stick a
filter over
> it that does nothing. Add a control interface that returns
statistics.
> Once you have something like that working, play with it -
add an Ioctl
> that swaps left and right buttons. Add another that reverses the
> direction of movement or rotates it. Stop it working altogether.
> Disable double clicks. Whatever.
>

Though the REST of Don’s recommendations are indeed excellent, I’d
suggest the Mouse is a particularly bad place to start.

If you’re “lucky” enough to have a test system with a floppy,
THAT makes
a particularly good device for you to filter. In fact, this
is one of
the very first exercises that we do in our WDM driver lab class.

It might be interesting to you to keep an eye out for some actual
hardware to write an example driver for. It’s hard to find such
hardware… It’s usually expensive, poorly documented,
complicated, and
not very interesting overall.

To meet the need for hardware for use in learning how to
write drivers,
we’re in the process of putting together a series of devices
specifically for this purpose. These will be available for purchase
from our web site. Some of these device we’ve designed/manfactured
ourselves, others we’ve worked special agreements out with the
manufacturer. ALL of them do things that have an interactive
component
to them (they have lights to light, switches to switch, etc),
and will
be sold to the community AT OUR COST (typically, less than $100), and
will come with example drivers. Look for the OSR designed
USB device to
be available within the next week or so for $74.

Peter
OSR


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@careful.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com

Don Ward wrote:

I chose the mouse because I figured the OP could do without it and it gave
him easy visual feedback on the effects of his tweaks. We all remember the
keyboard shortcuts don’t we?

Yeah, if the only worry is having to do without it, then there’s no
problem. I’m quite capable of survival with no mouse.

BTW, yes, I am using boneyard hardware for this stuff. Actually, most
of the stuff I’m doing now is in a VM (VPC), so all I need to do is
copy a file to recover.


Steve Johnson

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Don Ward[SMTP:xxxxx@careful.co.uk]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, January 27, 2005 6:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Training Question

Also, if you possibly can, make the system partition FAT. If your system
blue screens at start up, you can sometimes get out of jail by replacing the
driver.sys file with a corrected one using a DOS boot floppy to access the
disk. Yes, there are other ways to do it, but this way is one of the
easiest.

On the other hand, FAT is much more fragile than NTFS which is (well, should be) resistant against FS structures corruption. Unexpected BSOD usually only causes zeroing of unwritten parts of opened files. To avoid it, use System Internals Sync utility(http://www.sysinternals.com/ntw2k/source/misc.shtml#sync) before new driver test or load.

Instead, I’d recommed to install two OSes to two partitions so if one can’t be booted, you can boot the second one and fix it. Both using registry editor or remove/replace failed driver. It should be also possible with recovery console but I never needed it. I use such configurations since my start with NT drivers at NT 3.51, use one computer debugging environment (SoftICE) and the only real problem I had was because of hw failure.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Another widely available (builtin) hardware which is well documented
is the serial port( NS 16450/16550). But beware the serial drivers
sources in the DDK are complex!

Using a Pin2-Pin3 connection on a DB-9 plug you could easily build a loop
device.

Norbert.

“There is nothing so small that can’t be blown out of proportion.”
---- snip ----

I’d recommend (at leas to start with) to send the data to another computer.
That way you don’t have to get both send and receive to work before you
know something is working.

So pin2 cross to Pin3 on the other end of th cable, and vice versa. May
want to jumper the CTS/RTS (or connect them in “cross” fashion).

You should be able to buy a 9-pin serial cable (null-modem cable) from any
reasonable computer shop for a few bucks.

Use Hyperterminal or some other terminal product to get see what’s coming
out and send data back.


Mats

xxxxx@lists.osr.com wrote on 01/28/2005 10:53:00 AM:

Another widely available (builtin) hardware which is well documented
is the serial port( NS 16450/16550). But beware the serial drivers
sources in the DDK are complex!

Using a Pin2-Pin3 connection on a DB-9 plug you could easily build a loop
device.

Norbert.

“There is nothing so small that can’t be blown out of proportion.”
---- snip ----


Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

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

ForwardSourceID:NT0000BC1E