I've been trying to learn WDM recently, and as I've actually begun
writing some code I've found myself often peering into the WDM header
files to look up the layout of structs, the possible values for enums,
and on a few occasions I've been pleasantly surprised to find the full
source of a few simple macros (ones like IoGetNextIrpStackLocation,
IoSetNextIrpStackLocation, IoSetCompletionRoutine, and
IoMarkIrpPending).

With all the subtle rules in driver land, it helps to see the
line-by-line detail of what the OS interface is doing (to know what
the driver has to do in order to cooperate with it). I find myself
often wanting to know more. The DDK samples demonstrate common
practices, but they don't show the underlying mechanisms. For
instance, today I was calling IoAllocateIrp and wondering which fields
of the IRP are "automatically" (as the DDK documentation says)
initialized and which ones the driver is expected to initialize. It
would be useful if the source of the entire OS was available, instead
of just the headers.

What if you just go back to Linux?

--PA

You have been asking questions on minutiae that no else trying to learn
drivers has ever asked that I know of. Most of us learn enough to develop
and go deeper as we need to. Having seen the source over the years, the
source will not help you. First it is huge, but more important you have
asked questions at times that are about things that can honestly be termed
"undefined". So if you had the source, you would learn how these
unimportant details work for a version, but what will you do when they
change tommorrow?

A lot of the DDK samples are the source from the kernel. With the current
WDK, the drivers are the latest from the Vista source for things like the
serial, the disk driver and the CD-ROM file system to name a few. Look at
these samples and other available publicly (even if you do have to signup
for OSR). While the source can help for a specific question such as "why
did this error code come back from a call", I have seen too many developers
get the source and go astray trying to use all kinds of "neat routines"
that Microsoft doesn't document.

One of the biggest flaws of open source, is you can't tell the interface
from the implementation. Is this particular routine supposed to be relied
on, or is this a piece of crap that was laid down to get the current
revision out. When you have questions like what IoAllocateIrp intializes
that is valid, though the bottom line is it initializes the fields that are
not described in the IRP_MJ_XXX documentation for a given IRP (Note: this
is implied in the DDK documentation). To satisfy you curiosity this time,
the following fields are initialized:

Type - to indicate it is an IRP
Size - to size allocated for the IRP
StackCount - to the stack size
CurrentLocation - to the stack size + 1
ApcEnvironment - to the current threads APC environment
ThreadListEntry - to a list head
Tail.Overlay.CurrentStackLocation - to the current location

Now that was not really useful, was it.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply




<BubbaGump> wrote in message
newso64m2d89p9uu6qic426980kvl7hgaam5g@4ax.com...

There is a huge difference between want and need. Besides which, I haven't
encountered a curious moment that couldn't be satisfied in a very short time
with WinDbg and IDAPro. It would be *nice* if source or private symbols were
available to all but in my view, this is a distraction from the job of a
kernel mode developer; writing compliant and safe code as per the docs and
guidelines that Microsoft issue.

A while back, a colleague and I had a conversation with Mark Russinovich. In
response to the question "Which is the better documented OS, Linux or
Windows?" without hesitation he answered Windows (which angered my Linux
zealot colleague...!) On balance, I have to agree. Having the Linux source
code available hasn't made my job as writing kernel mode software
significantly easier. Microsoft Press and the DDK/WDK docs have though.

My last foray into Linux was at a time when Linus had forbidden interactive
debugging of the kernel. I dont know about anyone else, but I find poring
through vast swathes of other peoples code tedious and unproductive
especially if you are unfamiliar with the source tree. Quite simply, I spent
more time searching through the source code than I did writing code and the
information I *needed* was actually accessible in books, online resources
and in particular, newsgroups in a fraction of the time.

My two penneth...

Carl