Re: 3rd party Device driver development tool or- pur- e wdm driver development..Which is the be

If you look at the app world today, virtually nobody writes to the OS API
level anymore. It takes too long, it’s too baroque, too byzantine, too error
prone. There are multiple levels of indirection and multiple degrees of
abstraction. MFC is big and powerful, but you don’t need to use it if you
feel uncomfortable dealing with elephants: you can use ATL, COM, or any of
the myriad of layers available out there. For example, take STL: in my mind
it makes zero sense to write any piece of code in C if you have the
equivalent STL class available; are you going to do a priority queue by hand
just because it’s inside your driver and the DDK says you should write it in
C ? Somehow I don’t buy that logic!

In fact, just renaming a blah.c file into blah.cpp already makes sense, for
example, we can make polymorphism work for us by redefining OS entry points
without redundant parameters that do nothing but fill up lines of code.
Didn’t someone say that a driver must be compact ? Well, it starts with your
source code.

The point is, samples are written to a class library standard, so if you use
the samples, you’re using the classes. And if you build yourself a nice
interface, no, you don’t need to learn the deep level - just like if I’m
using ATL I don’t need to know about low level OS APIs.

And then, where does it stop ? Are you going to write directly to the OS, or
do you agree to use Winsock ? Are you going to write direct to the OS, or do
you agree to use OpenGL ? I believe that the onion peel principle applies
fully here: the higher level we can afford to operate, the easier it is to
write code and get it working.


-----Original Message-----
From: Peter Viscarola []
Sent: Tuesday, October 30, 2001 1:55 PM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or- pure
wdm driver development…Which is the best???

wrote in message news:xxxxx@ntdev…
> You have to know what you are doing period, I will agree with that. But,
> you don’t have to know everything to get productive. For instance you
> don’t necessarily need to know how to read/write the registry, or setup a
> device interface, or setup an INF, or a million other little things to get
> your driver out the door if you have a toolkit to help you. You should
> learn these things, but you shouldn’t be held up by them.
> Plus which do you think is faster. Trying to figure out how to write a
> scatter/gather DMA driver that works on 98 and 2000 with just the DDK. Or
> with real world samples and library code written by experts?

Let us not confuse the issue of using a toolkit or class library with having
a set of “samples… written by experts.” Bring on an extended set of
examples based on the DDK!

The question isn’t: “Is it better to re-invent all your own code, or use
code that somebody else wrote that you have good reason to believe will
work.” Duh! Who can argue that it’s not good to re-invent the wheel.

The question IS: “Is it better to use a set of abstractions that are layered
on to top of the ones that the operating system defines… or is it better
to work directly with the operating system’s interface.”

I’d argue it’s better to just use the interface the O/S defines… It’s the
one that’s mandatory. What possible advantage is there to my having to
learn MORE stuff, yet ANOTHER interface, if I’m gonna have to also learn the
O/S interface anyways.

During the discussion, somebody wrote: “It’s sorta like MFC for drivers.”
I’d say that’s a good analogy. As long as you try to use those friggin’ MFC
routines PRECISELY the way they were intended, and the way the examples are
written, everything’s great. But veer off the path even SLIGHTLY, and ugh!
You can be off spending days trying to figure out why the damn list control
(or whatever) doesn’t work the way it’s documented. Not to mention that
fact that I really don’t mind sloppy, enormous, plodding, inefficient code
that MFC produces in the sorts of user-mode programs that I write (which
are, essentially, throwaways). But I’m thinkin’ that I’d prefer my driver
code not sink to that level.


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

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