Neither Peter nor I said that anything was wrong with Numega’s or any others
development environments. What we said was that DDK knowledge and
familiarity not does not hurt, and in the long run is vital in kernel mode
programming. Anyone’s build environments, yours or god-knows-whom, work …
no question about that … whether C++ or C (which is an entire other
religious debate.)
However - they isolate the developer from the OS. That’s fine when your in a
hurry, and it’s a really brain-dead simple driver the boss’s uncles nephews
third cousins fifth son could do in his sleep on a his GameBoy. (Deliberate
exaggeration there :)) The point is that things go bump in the night and
quit working. I cannot recount the hours I have spent stepping through
assembler code in the kernel because I had a problem that required me to
understand how the HAL was doing things so I could fix my code. A
development environment such as yours, using C++, would have compounded that
tiptoeing through the tulips to the point it makes my brain hurt.
Beside all that … knowing and working around the bugs in the DDK is
difficult enough without throwing in the bugs of a 3rd party development
environment.
Let he/she/it who writes perfect code, cast the first stone. (Not me bubba,
I just dropped my rock.)
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Monday, October 29, 2001 1:21 PM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure wdm
driver development…Which is the best???
Let me plug in my own here 
I see using a class library as “MFC for drivers”. You want to write it all
from scratch ? Fine with me. But hey, there are all those components out
there, ready to be used, why reinvent the wheel ?
Then, you do it in C++, not in C. That is a *major* difference in terms of
productivity, even if you don’t use any of the available libraries. There is
no comparison between writing code in C++ and writing it in C. I’d rather
leverage on a driver written in C++ than on a driver written in C.
More, a class library isolates you from nonsense. The fact that one must
know how to drive the model doesn’t mean one must know the whole of the
model, neither does it mean one must know all of the DDK. Using class
libraries makes knowing much of the DDK unnecessary, and you program to a
model that’s much more pliable than the plain vanilla C in the DDK. You
minimize your interface with the OS, and you are left with a lot more time
and energy to concentrate on your own code and on driving your own hardware.
As for debugging, you’re going to have to do it anyway, and debugging other
people’s code can be hard - call it DDK or class library, it’s the same. But
debugging C++ is a lot easier than debugging C code.
So my take is, give me a minimalist and stable API into the OS, that doesn’t
change every OS release. Give me the ability of writing drivers in C++. Give
me an environment where I don’t need to worry about the OS getting between
me and my hardware, give me components that I can use and avoid reinventing
the wheel. Give me a clear separation between driving my hardware and
driving the OS.
And hey, what’s wrong with our marvellous Numega support ?
Alberto.
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Monday, October 29, 2001 3:58 PM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure
wdm driver development…Which is the best???
these two things could discuss issues on both the commercial and technical
advantages and
disadvantages of each of them…
Well, I say go with the base DDK.
I have three reasons:
a) If you use an existing toolkit/class library, you’re increasing what you
have to learn significantly. You’re gonna have to learn how to write
drivers using the DDK no matter what. If you don’t laern how to write
drivers the native DDK way you’ll never be able to read any of the DDK
explanatory material, or any of the books written on NT driver writing. You
certainly can’t expect whatever company you’re sourcing your toolkit/class
library from to be able to supply you info on EVERY kind of driver, in EVERY
situation. Hey, maybe you’d just like to read somebody else’s description
of what’s going on.
b) If you use the ddk, you have lots of potential assistance: There’s MS
support, there’s peer help from this forum, there’s The NT Insider, there
are other forums. With Vendor X’s toolkit/class library you get help from
Vendor X, and maybe their user group.
c) When you have a tough problem, you’re gonna wind-up debugging YOUR
driver, and Vendor X’s toolkit/class library code. Sure, the problem is
almost certainly in your driver, cuz Vendor X has no bugs… let’s assume
that. But the process of debugging a hard problem is gonna cause you to
have to walk through Vendor X’s stuff… cuz, after all, it IS ultimately
Windows that you’re interfacing with and that you need to make happy. You
new a device object and get back STATUS_UNSUCCESSFUL (or whatever)…
where’s the problem?
So you see, to be really effective there’s really no way to escape knowing
the native DDK interface, cuz that’s the interface that the O/S utilizes.
Might as well make it easy on yourself, and “bite the bullet” and use the
DDK.
Peter
OSR
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@broadstor.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