There are times I think giving up computers and joining a monastery that
runs naked through rose bushes would be more fun.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, October 30, 2001 6:59 PM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure wdm
driver developmentā¦Which is the best???
Didnāt you mean naked and not raw
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary Little
Sent: Tuesday, October 30, 2001 2: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???
Alberto,
I think you really mean SI DDK in the following ā¦
"And you know what, we had to make our drivers work, therefore chances
are that those DDK bugs will have been ironed out by the time the sample
code gets to your hands ! "
No, Alberto, the bugs you KNOW about will be ironed out. Do you mean to
imply that your software and drivers are exercised in EVERY possible
configuration, with EVERY possible input, on EVERY possible hardware
platform BEFORE you make a release? Get real. SoftIce is like anyone
else ā¦ You work it until all known bugs are taken care of, prioritized
for further work, and you have confidence in the product. You cannot and
will not release a bug free product. All you need to do is read the news
group to find out SI still has bugs. In any release.
Summing it all up, however, it boils down to āWhoās on firstā If you
work for a house that produces development environments then you are PRO
commercial toolkits and APIs. If your one of the MANY schmucks that do
NOT work for one of those houses you are probably 50/50. Youāve had good
luck with the ones youāve used, but if you have been doing kernel mode
development for any length of time you prefer programming in the raw.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, October 30, 2001 12:19 PM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure
wdm driver developmentā¦Which is the best???
I was joking when I talked about Numegaās support, no intention to
ruffle anyoneās feathers. But by now you probably know how I feel about
knowing the OS - Iāll bypass it before Iāll learn it, and I believe that
the less I have to know about it, the better. With C++, a lot of things
that used to go bump in the night donāt any more, but of course that
takes a total repositioning of oneās programming paradigms. And you know
what, we had to make our drivers work, therefore chances are that those
DDK bugs will have been ironed out by the time the sample code gets to
your hands !
Alberto.
-----Original Message-----
From: Gary Little [mailto:xxxxx@Broadstor.com]
Sent: Tuesday, October 30, 2001 11:58 AM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure
wdm driver developmentā¦Which is the best???
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: 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: xxxxx@storagecraft.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