Hi friends,
I would like to discuss here which would be the best option
whether to go for 3rd party device driver development tool or Building own .sys driver using WDM…if anybody more experienced with
these two things could discuss issues on both the commercial and technical advantages and disadvantages of each of them…
thanx,
shiv
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
> 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: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Sorry, I am trying to not promote my products here or on the newsgroups as
I know this has and does piss people off, but I was asked.
As I work on WinDK for bSquare Corporation, of course I have to
respectfully disagree with Peter, (quite the risky thing to do BTW :).
But, honestly I think this question depends a lot on your needs. If you
want a tool that will get you 0-60 faster than your competition could ever
even think of getting there, use a tool like WinDK. I can generate a fully
functioning WDM driver complete with full Pnp handling and Power management
and start knocking the hardware around in about 2 minutes. Of course a
commercial quality driver takes some time no matter what you do, but the
wizards, samples, and libraries take out soooo much of the crap of writing
drivers it isn’t even funny. I recommend a toolkit for the following
reasons:
a.) It is nearly impossible to find a DDK sample that does what you want,
while toolkits like WinDK provide samples for the latest 3rd party devices
like PLX9054 for PCI, or EZ-Usb by Cypress for USB. And, they provide
samples that do what you want like scatter/gather DMA. Just try to find a
scatter/gather DMA sample in the DDK, I dare you, much less one for a
PLX9054 device.
b.) You get support with WinDK that even on our worst day is better than
the alternative. But, you don’t lose anything with WinDK either, its still
based on the DDK, so all other avenues of support are still available to
help you understand the DDK. WinDK does have its own learning curve to
some degree, but if you are new to drivers, you will get going a whole lot
faster with WinDK and the sample code it provides than with the DDK by
itself. I speak from experience. Besides with our current limited time
low price, ($750 for US customers) what do you have to lose really? There
are no royalties either.
c.) You have sample library and sample driver code to show you how to use
the DDK functions properly. WinDK unlike some of our competitors tries
really hard not to obfuscate or abstract the DDK more than is useful, and
you can use straight DDK calls anywhere in a WinDK driver you like. We
also have setup our C++ classes such that they are as light as possible,
and you can overload just about anything you want. C is harder because it
is C, but you can still customize it anyway you like.
d.) Do you honestly have time on your current project to go in and figure
out how to read/write the registry, create your own device IRP queues,
truly handle Power correctly, handle all of the PNP IRPs correctly, setup
scatter/gather DMA correctly on 98 and 2000, handle
MmGetSystemAddressForMdl correctly on NT4 all service packs, 98, and 2000,
setup your symbolic link and/or device interface correctly, write a test
app for your driver correctly, setup your INF correctly for 98/Me/2000/XP
or your REG file for NT4, or about a hundred other things you may have to
learn to do and that may not be documented well if at all in the DDK, (DDK
documentation is less of a problem now thanks to the bug bash :)?? Why not
get your project out the door and delve deeper into the items you might be
weak on as you have time?
e.) Debugging WinDK code is just as easy as any other driver. I debugged a
WinDK WDM bus driver with two child FDO drivers simultaneously, both C and
C++ versions for each driver, and it wasn’t anymore difficult than
debugging a DDK sample. And, C++ is every bit as easy as C. However, if
you are a C programmer this may not be true for you. But, WinDK offers C
support as well as C++ so take your pick.
f.) We have Wizards to generate a fully building and working driver shell
in C or C++. Our Wizards can generate device or filter drivers for WDM and
NT4 platforms. This alone saves me so much time so as to not even make
this argument worthwhile, but, obviously, I am very familiar with WinDK.
g.) WinDK takes care of a whole bunch of the cross-platform issues between
98 and 2000. With WinDK you can produce a cross-platform binary compatible
WDM driver for USB, 1394, PCI, and others that will work on 98
Gold/98SE/Me/2000/XP. Why try to figure all of this minutia out on your
own? I mean you could, but why?
h.) We have hundreds of users kicking our code around everyday. Your self
created DDK driver is likely to never get that kind of exposure. And we
still find errors! It would be difficult to get the level of reliability
toolkits offer on your own.
I see a lot of posts from people who either have never used a toolkit, or
used a bad one, or missused one (which can happen). Having become familiar
with WinDK, I would never go without a toolkit like this again. It helped
when I didn’t know much, it helped me learn, and it helps more than ever
now that I know the ins and outs of Windows kernel mode drivers. Unlike
MFC, it isn’t a big huge beast that gets in the way, it is a really good
toolkit designed and implemented by some of the best driver developers on
the planet. It does provide all of the usefulness something like MFC
provides in that it takes out a lot of the guesswork and makework in
developing a driver. We have used it on numerous custom contracts
including some that tested the limits pretty darn hard, and WinDK has
always proved to be a big help.
Just my $0.02. BTW, WinDK 3.0 was just released and we have a fully
functional 30-day evaluation version available for free download at:
www.bsquare.com/products/devtools/WinDK
So try it out and try creating a driver for your device and see what you
think for yourself. Compare us against doing it straight DDK, or against
our competition. I will put my money where my mouth is. Good luck!
Bill “I get no commission, bonus or other, if you buy it or not” McKenzie
Software Engineer
bSquare Corporation
On 10/29/01, ““Peter Viscarola” ” wrote:
> > 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: $subst(‘Recip.EmailAddr’)
> 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
What kind of driver do you want to develop?
If something non-trivial - then only bare DDK can be used, any toolkit will introduce problems and not solve it.
But if something plain - like NDIS/WDM driver for an USB network hardware - then try the toolkits like bSquare’s one.
Max
----- Original Message -----
From: Shiva prasad T.S.
To: NT Developers Interest List
Sent: Sunday, September 29, 2002 2:14 PM
Subject: [ntdev] 3rd party Device driver development tool or pure wdm driver development…Which is the best???
Hi friends,
I would like to discuss here which would be the best option
whether to go for 3rd party device driver development tool or Building own .sys driver using WDM…if anybody more experienced with
these two things could discuss issues on both the commercial and technical advantages and disadvantages of each of them…
thanx,
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
Not trying to get into a religious war here, I know a lot of people don’t
like toolkits for whatever reasons, and I am not about to convince
otherwise. But what do you consider non-trivial? I mean WinDK doesn’t
handle FileSystem, SCSI, or NDIS drivers, it just isn’t designed for those
APIs, although we might add extensions to that effect. But, you can make
any kernel call you like in a WinDK driver, so there is no device you can’t
handle if you want to. We have done some fairly knarly custom work.
Extending C++ is basically what C++ was designed for. WinDK may not help
in all cases, but it won’t hurt in most cases either. Then you still get
the IRP queues, IRP handling functions, registry functions, DMA functions,
all that crap that once you know how it works you are just going to cut and
paste it anyway. I don’t understand why most people don’t get that. Even
Walter Oney has created a framework for himself. I bet he can get a
contract done a whole lot faster than his competition using the straight
DDK 
Every WDM driver is going to have to handle PNP and Power, why
reinvent the wheel?
Bill M.
What kind of driver do you want to develop?
If something non-trivial - then only bare DDK can be used, any toolkit =
will introduce problems and not solve it.But if something plain - like NDIS/WDM driver for an USB network =
hardware - then try the toolkits like bSquare’s one.Max
----- Original Message -----=20
From: Shiva prasad T.S.=20
To: NT Developers Interest List=20
Sent: Sunday, September 29, 2002 2:14 PM
Subject: [ntdev] 3rd party Device driver development tool or pure wdm =
driver development…Which is the best???Hi friends,
I would like to discuss here which would be the best option
whether to go for 3rd party device driver development tool or Building =
own .sys driver using WDM…if anybody more experienced with
these two things could discuss issues on both the commercial and =
technical advantages and disadvantages of each of them…thanx,
shiv
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=20
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------=_NextPart_000_0096_01C160AB.1B33FAB0
Content-Type: text/html;
charset=“ISO-8859-1”
Content-Transfer-Encoding: quoted-printable
> charset=3Diso-8859-1">
What kind of driver do you want to =
> develop?
If something non-trivial - then only bare DDK =
> can be=20
> used, any toolkit will introduce problems and not solve it.
But if something plain - like NDIS/WDM driver for an =
> USB=20
> network hardware - then try the toolkits like bSquare’s =
> one.
Max
> style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
> BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
>
----- Original Message ----->
> style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
> black"> From: =20
> > href=3D"mailto:xxxxx@yahoo.com">Shiva=20
> prasad T.S.>
To: > title=xxxxx@lists.osr.com=20
> href=3D"mailto:xxxxx@lists.osr.com">NT Developers Interest List =
>>
Sent: Sunday, September 29, =
> 2002 2:14=20
> PM>
Subject: [ntdev] 3rd party =
> Device driver=20
> development tool or pure wdm driver development…Which is the =
> best???>
>
Hi friends,>
>
I would like to =
> discuss here=20
> which would be the best option>
>
whether to go for 3rd party device =
> driver=20
> development tool or Building own .sys driver using WDM…if anybody =
> more=20
> experienced with>
these two things could discuss issues =
> on both the=20
> commercial and technical advantages and disadvantages of each of=20
> them…>
>
thanx,>
>
shivYou are =
> currently=20
> subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send =
> a blank=20
> 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
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
------=_NextPart_000_0096_01C160AB.1B33FAB0–
> - There are cases you can have all your hardware access code in the use
mode. Writing driver in user mode isolates the programmer from any DDK/kernel.
Any such tools are just plain harmful, since they degrade the NT’s stability to a Win9x level of stability.
No normal OS must allow user mode accesses to the hardware just because the developer is lazy or his boss has tight deadlines.
Max
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 have not seen any mention to Numega (Compuware) C++ Framework: DriverWorks
and DriverNetworks. It is an indispensible code repository. This C++
framework fully supports NDIS 4, NDIS 5, TDI Client interfaces (infact has
Kernel level full socket class libraries), NDIS_WDM, and full WDM driver
support. There are two Wizards with rich capabilities. As to the debugging
of the code, I use both SofICE and the latest WinDbg. I have no problem
debugging C++ code.
Numega customer support is great and Numega development term always listens
to the developers in adding new features/revising existing ones. Also, there
is no need to resort to command line tools to build your drivers. The
development is fully integrated into VC++ 6 IDE with full support of
ClassView, Browser etc.
One of the Cons of using C++ frameworks is that it creates new abstractions
that if you run into areas that the framework does not support and you need
to start using DDK, then it may take time to understand the underlying DDK
calls for the Class abstactions. But it is true for any kind of C++
framework. Also there is a danger of too-much-isolation from the “real
world” of DDK.
One benefit one receive from such frameworks is tha the repository is fully
tested. You don’t have to re-invent the standard responses to OS callbacks
(like PnP IRPs etc.).
Of course such frameworks has limited domain. I have yet to see any
framework that would have support for SCSI etc. development.
I am sure WinDK is equally well written. I have been using Numega
DriverNetworks and DriverWorks for at least 3 years and hardly thinking
going back to pure DDK unless I have to. I highly recommend C++ frameworks.
-FC
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 have not seen any mention to Numega (Compuware) C++ Framework:
DriverWorks and DriverNetworks.<<
I mentioned it several posts ago. Sucks! VtoolsD, however, is great for
the wrappers.
>It is an indispensible code repository. This C++ framework fully
supports NDIS 4, NDIS 5, TDI Client interfaces (infact has Kernel level
full socket class libraries), NDIS_WDM, and full WDM driver support.
There are two Wizards with rich capabilities. As to the debugging of the
code, I use both SofICE and the latest WinDbg. I have no problem
debugging C++ code.<<
How about file systems and storage class drivers?
>Numega customer support is great<<
Yes. This is true. I am a SI users.
>One of the Cons of using C++ frameworks is that it creates new
abstractions that if you run into areas that the framework does not
support and you need to start using DDK, then it may take time to
understand the underlying DDK calls for the Class abstactions. But it is
true for any kind of C++ framework. Also there is a danger of
too-much-isolation from the “real world” of DDK.<<
Many years ago, in the early 4.0 days, I started a C++ class framework
for NT drivers. I did it as an exercise to see if it were possible to do
a good one; not like the ones out. It is possible. I found that I was
spending more time tweaking and screwing with the classes than I did
writing the driver code. Again, C++ OO shines when it is used in larger
projects with multiple developers. If you have a single driver with
multiple developers, then the driver is too large.
I simply can not understand the need to use OO methodologies in a device
driver that is always a relatively small effort. I suspect most of the
drivers written using these class libraries have more code in the
classes than in the functional code constructed with the classes in the
driver. That makes no sense in the world of KM drivers.
>One benefit one receive from such frameworks is tha the repository is
fully tested. You don’t have to re-invent the standard responses to OS
callbacks (like PnP IRPs etc.).<<
This assumes that the developer(s) of the class libraries know more than
we do. Who is to say that a class developer has more knowledge about the
functionality of the OS than the person writing the drivers. I contend
that there is more to gain writing the actual drivers. If you spend all
of your time building tools, you never get to know the aspects of
writing an actual driver; only tools.
>Of course such frameworks has limited domain. I have yet to see any
framework that would have support for SCSI etc. development.<<
Yes. I have seen no good class libraries that suppoer the storage stack.
Jamey
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
>How about file systems and storage class drivers?
We’ve developed storage classes at Acronis. What do you think about such a
code:
class KMyDriver : public KVolumeFilterDriver
{
protected:
KVolumeFilter* OnAddDevice(PDEVICE_OBJECT pPDO) { return new
KVolumeFilter(pPDO); }
};
KVolumeFilterDriver g_Driver;
the upper code is a skeleton of a driver filtering volumes. Just inherit
your own class from KVolumeFilter, write your own virtual functions
(OnWrite, OnRead, etc.) and the filter is ready
Yes. I have seen no good class libraries that suppoer the storage stack.
Our library rules
Regards,
Max
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Wednesday, October 31, 2001 8:02 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 have not seen any mention to Numega (Compuware) C++ Framework:
DriverWorks and DriverNetworks.<<
I mentioned it several posts ago. Sucks! VtoolsD, however, is great for
the wrappers.
>It is an indispensible code repository. This C++ framework fully
supports NDIS 4, NDIS 5, TDI Client interfaces (infact has Kernel level
full socket class libraries), NDIS_WDM, and full WDM driver support.
There are two Wizards with rich capabilities. As to the debugging of the
code, I use both SofICE and the latest WinDbg. I have no problem
debugging C++ code.<<
How about file systems and storage class drivers?
>Numega customer support is great<<
Yes. This is true. I am a SI users.
>One of the Cons of using C++ frameworks is that it creates new
abstractions that if you run into areas that the framework does not
support and you need to start using DDK, then it may take time to
understand the underlying DDK calls for the Class abstactions. But it is
true for any kind of C++ framework. Also there is a danger of
too-much-isolation from the “real world” of DDK.<<
Many years ago, in the early 4.0 days, I started a C++ class framework
for NT drivers. I did it as an exercise to see if it were possible to do
a good one; not like the ones out. It is possible. I found that I was
spending more time tweaking and screwing with the classes than I did
writing the driver code. Again, C++ OO shines when it is used in larger
projects with multiple developers. If you have a single driver with
multiple developers, then the driver is too large.
I simply can not understand the need to use OO methodologies in a device
driver that is always a relatively small effort. I suspect most of the
drivers written using these class libraries have more code in the
classes than in the functional code constructed with the classes in the
driver. That makes no sense in the world of KM drivers.
>One benefit one receive from such frameworks is tha the repository is
fully tested. You don’t have to re-invent the standard responses to OS
callbacks (like PnP IRPs etc.).<<
This assumes that the developer(s) of the class libraries know more than
we do. Who is to say that a class developer has more knowledge about the
functionality of the OS than the person writing the drivers. I contend
that there is more to gain writing the actual drivers. If you spend all
of your time building tools, you never get to know the aspects of
writing an actual driver; only tools.
>Of course such frameworks has limited domain. I have yet to see any
framework that would have support for SCSI etc. development.<<
Yes. I have seen no good class libraries that suppoer the storage stack.
Jamey
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@acronis.ru
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
small fixes
class KMyFilter : public KVolumeFilter
{
public:
virtual KSTATUS OnWrite(KIrp* pIrp) { /* do what you want here */ return
KSTATUS_CALLDOWN; }
};
class KMyDriver : public KVolumeFilterDriver
{
protected:
virtual KVolumeFilter* OnAddDevice(PDEVICE_OBJECT pPDO) { return new
KMyFilter(pPDO); }
};
KMyDriver g_Driver;
Regards,
Max
-----Original Message-----
From: Max Lyadvinsky [mailto:xxxxx@acronis.ru]
Sent: Wednesday, October 31, 2001 9:54 PM
To: ‘NT Developers Interest List’
Subject: RE: [ntdev] Re: 3rd party Device driver development tool or pure
wdm driver development…Which is the best???
How about file systems and storage class drivers?
We’ve developed storage classes at Acronis. What do you think about such a
code:
class KMyDriver : public KVolumeFilterDriver
{
protected:
KVolumeFilter* OnAddDevice(PDEVICE_OBJECT pPDO) { return new
KVolumeFilter(pPDO); }
};
KVolumeFilterDriver g_Driver;
the upper code is a skeleton of a driver filtering volumes. Just inherit
your own class from KVolumeFilter, write your own virtual functions
(OnWrite, OnRead, etc.) and the filter is ready
Yes. I have seen no good class libraries that suppoer the storage stack.
Our library rules
Regards,
Max
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Wednesday, October 31, 2001 8:02 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 have not seen any mention to Numega (Compuware) C++ Framework:
DriverWorks and DriverNetworks.<<
I mentioned it several posts ago. Sucks! VtoolsD, however, is great for
the wrappers.
>It is an indispensible code repository. This C++ framework fully
supports NDIS 4, NDIS 5, TDI Client interfaces (infact has Kernel level
full socket class libraries), NDIS_WDM, and full WDM driver support.
There are two Wizards with rich capabilities. As to the debugging of the
code, I use both SofICE and the latest WinDbg. I have no problem
debugging C++ code.<<
How about file systems and storage class drivers?
>Numega customer support is great<<
Yes. This is true. I am a SI users.
>One of the Cons of using C++ frameworks is that it creates new
abstractions that if you run into areas that the framework does not
support and you need to start using DDK, then it may take time to
understand the underlying DDK calls for the Class abstactions. But it is
true for any kind of C++ framework. Also there is a danger of
too-much-isolation from the “real world” of DDK.<<
Many years ago, in the early 4.0 days, I started a C++ class framework
for NT drivers. I did it as an exercise to see if it were possible to do
a good one; not like the ones out. It is possible. I found that I was
spending more time tweaking and screwing with the classes than I did
writing the driver code. Again, C++ OO shines when it is used in larger
projects with multiple developers. If you have a single driver with
multiple developers, then the driver is too large.
I simply can not understand the need to use OO methodologies in a device
driver that is always a relatively small effort. I suspect most of the
drivers written using these class libraries have more code in the
classes than in the functional code constructed with the classes in the
driver. That makes no sense in the world of KM drivers.
>One benefit one receive from such frameworks is tha the repository is
fully tested. You don’t have to re-invent the standard responses to OS
callbacks (like PnP IRPs etc.).<<
This assumes that the developer(s) of the class libraries know more than
we do. Who is to say that a class developer has more knowledge about the
functionality of the OS than the person writing the drivers. I contend
that there is more to gain writing the actual drivers. If you spend all
of your time building tools, you never get to know the aspects of
writing an actual driver; only tools.
>Of course such frameworks has limited domain. I have yet to see any
framework that would have support for SCSI etc. development.<<
Yes. I have seen no good class libraries that suppoer the storage stack.
Jamey
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@acronis.ru
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
Good to know.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Max Lyadvinsky
Sent: Wednesday, October 31, 2001 10:54 AM
To: NT Developers Interest List
Subject: [ntdev] Re: 3rd party Device driver development tool or pure
wdm driver development…Which is the best???
How about file systems and storage class drivers?
We’ve developed storage classes at Acronis. What do you think about such
a
code:
class KMyDriver : public KVolumeFilterDriver
{
protected:
KVolumeFilter* OnAddDevice(PDEVICE_OBJECT pPDO) { return new
KVolumeFilter(pPDO); } };
KVolumeFilterDriver g_Driver;
the upper code is a skeleton of a driver filtering volumes. Just inherit
your own class from KVolumeFilter, write your own virtual functions
(OnWrite, OnRead, etc.) and the filter is ready
Yes. I have seen no good class libraries that suppoer the storage
stack.
Our library rules
Regards,
Max
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Wednesday, October 31, 2001 8:02 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 have not seen any mention to Numega (Compuware) C++ Framework:
DriverWorks and DriverNetworks.<<
I mentioned it several posts ago. Sucks! VtoolsD, however, is great for
the wrappers.
>It is an indispensible code repository. This C++ framework fully
supports NDIS 4, NDIS 5, TDI Client interfaces (infact has Kernel level
full socket class libraries), NDIS_WDM, and full WDM driver support.
There are two Wizards with rich capabilities. As to the debugging of the
code, I use both SofICE and the latest WinDbg. I have no problem
debugging C++ code.<<
How about file systems and storage class drivers?
>Numega customer support is great<<
Yes. This is true. I am a SI users.
>One of the Cons of using C++ frameworks is that it creates new
abstractions that if you run into areas that the framework does not
support and you need to start using DDK, then it may take time to
understand the underlying DDK calls for the Class abstactions. But it is
true for any kind of C++ framework. Also there is a danger of
too-much-isolation from the “real world” of DDK.<<
Many years ago, in the early 4.0 days, I started a C++ class framework
for NT drivers. I did it as an exercise to see if it were possible to do
a good one; not like the ones out. It is possible. I found that I was
spending more time tweaking and screwing with the classes than I did
writing the driver code. Again, C++ OO shines when it is used in larger
projects with multiple developers. If you have a single driver with
multiple developers, then the driver is too large.
I simply can not understand the need to use OO methodologies in a device
driver that is always a relatively small effort. I suspect most of the
drivers written using these class libraries have more code in the
classes than in the functional code constructed with the classes in the
driver. That makes no sense in the world of KM drivers.
>One benefit one receive from such frameworks is tha the repository is
fully tested. You don’t have to re-invent the standard responses to OS
callbacks (like PnP IRPs etc.).<<
This assumes that the developer(s) of the class libraries know more than
we do. Who is to say that a class developer has more knowledge about the
functionality of the OS than the person writing the drivers. I contend
that there is more to gain writing the actual drivers. If you spend all
of your time building tools, you never get to know the aspects of
writing an actual driver; only tools.
>Of course such frameworks has limited domain. I have yet to see any
framework that would have support for SCSI etc. development.<<
Yes. I have seen no good class libraries that suppoer the storage stack.
Jamey
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@acronis.ru
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
** Reply to message from “Moreira, Alberto” on
Fri, 2 Nov 2001 09:52:03 -0500
OK, I’m walking out into the middle of the mailing list. Deeeep breath. Look
around a bit. Fingers in ears. Another deep breath. OK, I’m ready. Let’s see
if this still works as an adult.
Aaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhh!!!
Aaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhh!!!
Aaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhh!!!
Aaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhh!!!
Sincerely,
Chris Myers
Senior Project Engineer
Quatech, Inc.
—
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