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

So, just 'cause I can’t help myself, (with kudos to Gary):

Peter, how would your position fit in with the hefty-priced OSR FSDK
toolkit?

Sorry, couldn’t help it.

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
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.

Peter
OSR


You are currently subscribed to ntdev as: xxxxx@stratus.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