Re: 3rd party Device driver development tool or pure wdm driver development..Which is the best

Didn’t you mean naked and not raw :slight_smile:

-----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. :slight_smile:

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 :slight_smile:

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 ? :slight_smile:

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: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I usually watch these threads pretty silently, but this time I feel I need
to bring a different perspective.

I’m a huge fan of tools, particularly Numega DriverWorks. I’ve done drivers
in assembler, C, and now ONLY do Windows drivers with DriverWorks.

The reality is that you can’t be ignorant of the DDK. If you are, then you
don’t deserve to be writing drivers. It doesn’t make sense. If you use a
tool to hide your ignorance, you deserve what you get… in fact one of my
more successful consulting assignments was a bailout of a VB programmer who
thought DriverWorks made it possible for him to crank out a video capture
driver. Duh!

However, I CAN crank out a driver at least 2 to 3 times faster with
DriverWorks. It handles all the grunt work that I’d need to code myself,
sets up the superstructure of the driver, and gives me tons of useful, well
organized classes for all kinds of things. The code in DriverWorks is
pretty mature. In the last 5 years, I’ve run across 3 or 4 problems, all
have gotten fixed pretty quickly. I suspect that my work has significantly
fewer defects because I’m using proven, well structured code.

I think I’ve been responsible in one way or another for about 20 drivers
and/or kernel mode DLLs built with the DriverWorks class library. On one
consulting project, it let me bid a fixed price for 1/2 the price of my
nearest competitor and I still made an excellent profit. Thinking now, I
probably left money on the table, but the customer was so impressed that
they came back for several other projects.

And as for debugging, SoftIce does very well with C++, in fact I use it for
debugging user mode services as well as drivers…and it’s so much easier
to get working than the alternative.

As a manager… (I have a group of 10 developers), I find that the code
produced in C++ is infinitely more understandable than most C code. We
follow coding standards, have great class library reuse, and I get far more
accurate schedules from my team.

OK… those that want to continue writing drivers with chisels and stone
tablets go ahead, me… I like my word processor. But don’t EVER think that
you don’t still need to know your grammer!

Enough Said! Back to enhancing my storage class driver written using
DriverWorks!

John K.

John A. Kowalonek
Block Island Software, Ltd.
22 Royal Crest Drive, Suite 1
Marlborough, MA 01752
phone (617)803-0798
fax (801)760-3861
mailto:xxxxx@blockislandsoftware.net
http://www.blockislandsoftware.net/

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary Little
Sent: Tuesday, October 30, 2001 5: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. :slight_smile:

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 :slight_smile:

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 marvelous Numega support ? :slight_smile:

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@blockislandsoftware.net
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

Chisels and stones?

I do not disagree with toolkits. I disagree with C++ OO in a KM driver.

You say that you are a program manager. What are you defect counts in
your drivers? How often do you have to have your people go in and fix
bugs?

Also, I would like to also know why MS uses C and not C++ OO in drivers;
not that you actually know, but I suspect you can speculate.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of John A. Kowalonek
Sent: Wednesday, October 31, 2001 4:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure
wdm driver development…Which is the best???

I usually watch these threads pretty silently, but this time I feel I
need to bring a different perspective.

I’m a huge fan of tools, particularly Numega DriverWorks. I’ve done
drivers in assembler, C, and now ONLY do Windows drivers with
DriverWorks.

The reality is that you can’t be ignorant of the DDK. If you are, then
you don’t deserve to be writing drivers. It doesn’t make sense. If you
use a tool to hide your ignorance, you deserve what you get… in fact
one of my more successful consulting assignments was a bailout of a VB
programmer who thought DriverWorks made it possible for him to crank out
a video capture driver. Duh!

However, I CAN crank out a driver at least 2 to 3 times faster with
DriverWorks. It handles all the grunt work that I’d need to code
myself, sets up the superstructure of the driver, and gives me tons of
useful, well organized classes for all kinds of things. The code in
DriverWorks is pretty mature. In the last 5 years, I’ve run across 3 or
4 problems, all have gotten fixed pretty quickly. I suspect that my
work has significantly fewer defects because I’m using proven, well
structured code.

I think I’ve been responsible in one way or another for about 20 drivers
and/or kernel mode DLLs built with the DriverWorks class library. On
one consulting project, it let me bid a fixed price for 1/2 the price of
my nearest competitor and I still made an excellent profit. Thinking
now, I probably left money on the table, but the customer was so
impressed that they came back for several other projects.

And as for debugging, SoftIce does very well with C++, in fact I use it
for debugging user mode services as well as drivers…and it’s so much
easier to get working than the alternative.

As a manager… (I have a group of 10 developers), I find that the code
produced in C++ is infinitely more understandable than most C code. We
follow coding standards, have great class library reuse, and I get far
more accurate schedules from my team.

OK… those that want to continue writing drivers with chisels and stone
tablets go ahead, me… I like my word processor. But don’t EVER think
that you don’t still need to know your grammer!

Enough Said! Back to enhancing my storage class driver written using
DriverWorks!

John K.

John A. Kowalonek
Block Island Software, Ltd.
22 Royal Crest Drive, Suite 1
Marlborough, MA 01752
phone (617)803-0798
fax (801)760-3861
mailto:xxxxx@blockislandsoftware.net
http://www.blockislandsoftware.net/

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary Little
Sent: Tuesday, October 30, 2001 5: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. :slight_smile:

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 :slight_smile:

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 marvelous Numega support ? :slight_smile:

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@blockislandsoftware.net
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: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

We shipped two major video conferencing systems this way, never had a blue
screen in the field. Don’t recall any problems related to tools or
environment that we used.

Current project is a storage system integrated into Win2K server appliance
kit. It’s been incredibly stable for the last 6 months. Blue screens have
not been a problem.

Remember, I didn’t say you didn’t need to know what you are doing…

I’m puzzled by people that think there’s some magic to C++. There isn’t
really. Vtables are just jump tables which we’ve all probably used. It’s
the same basic runtime except that the object pointer is passed in with the
function call. I can read the code easier, I can debug the code easier. Am
I missing something?

John A. Kowalonek
Block Island Software, Ltd.
22 Royal Crest Drive, Suite 1
Marlborough, MA 01752
phone (617)803-0798
fax (801)760-3861
mailto:xxxxx@blockislandsoftware.net
http://www.blockislandsoftware.net/

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Wednesday, October 31, 2001 11:47 AM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure wdm
driver development…Which is the best???

Chisels and stones?

I do not disagree with toolkits. I disagree with C++ OO in a KM driver.

You say that you are a program manager. What are you defect counts in
your drivers? How often do you have to have your people go in and fix
bugs?

Also, I would like to also know why MS uses C and not C++ OO in drivers;
not that you actually know, but I suspect you can speculate.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of John A. Kowalonek
Sent: Wednesday, October 31, 2001 4:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure
wdm driver development…Which is the best???

I usually watch these threads pretty silently, but this time I feel I
need to bring a different perspective.

I’m a huge fan of tools, particularly Numega DriverWorks. I’ve done
drivers in assembler, C, and now ONLY do Windows drivers with
DriverWorks.

The reality is that you can’t be ignorant of the DDK. If you are, then
you don’t deserve to be writing drivers. It doesn’t make sense. If you
use a tool to hide your ignorance, you deserve what you get… in fact
one of my more successful consulting assignments was a bailout of a VB
programmer who thought DriverWorks made it possible for him to crank out
a video capture driver. Duh!

However, I CAN crank out a driver at least 2 to 3 times faster with
DriverWorks. It handles all the grunt work that I’d need to code
myself, sets up the superstructure of the driver, and gives me tons of
useful, well organized classes for all kinds of things. The code in
DriverWorks is pretty mature. In the last 5 years, I’ve run across 3 or
4 problems, all have gotten fixed pretty quickly. I suspect that my
work has significantly fewer defects because I’m using proven, well
structured code.

I think I’ve been responsible in one way or another for about 20 drivers
and/or kernel mode DLLs built with the DriverWorks class library. On
one consulting project, it let me bid a fixed price for 1/2 the price of
my nearest competitor and I still made an excellent profit. Thinking
now, I probably left money on the table, but the customer was so
impressed that they came back for several other projects.

And as for debugging, SoftIce does very well with C++, in fact I use it
for debugging user mode services as well as drivers…and it’s so much
easier to get working than the alternative.

As a manager… (I have a group of 10 developers), I find that the code
produced in C++ is infinitely more understandable than most C code. We
follow coding standards, have great class library reuse, and I get far
more accurate schedules from my team.

OK… those that want to continue writing drivers with chisels and stone
tablets go ahead, me… I like my word processor. But don’t EVER think
that you don’t still need to know your grammer!

Enough Said! Back to enhancing my storage class driver written using
DriverWorks!

John K.

John A. Kowalonek
Block Island Software, Ltd.
22 Royal Crest Drive, Suite 1
Marlborough, MA 01752
phone (617)803-0798
fax (801)760-3861
mailto:xxxxx@blockislandsoftware.net
http://www.blockislandsoftware.net/

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary Little
Sent: Tuesday, October 30, 2001 5: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. :slight_smile:

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 :slight_smile:

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 marvelous Numega support ? :slight_smile:

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@blockislandsoftware.net
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@blockislandsoftware.net
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