Does anyone have any information or tips on porting from Compuware’s DriverWorks to KMDF? We’ve finally released version 1 of the our product, so we’re probably going to do our port away from DriverWorks very soon. I’ve starting reading the WMD to KMDF guide, but I was wondering if anyone has any more specific advice.
Thanks!
Michael Kohne
xxxxx@kohne.org
“You must be smarter than the equipment you are trying to operate.”
Scrap all the crap around your device specific code and start from
scratch with KMDF. You should be able to salvage general algorithms and
device specific operations, other than that not much else is going to be
the same. That said, depending on what you are doing, in general a
from-scratch KMDF prototype is a one or two week task. Don’t worry about
conversion. Scrap that puppy and move on.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Kohne
Sent: Monday, November 06, 2006 12:08 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Compuware DriverWorks to KMDF porting information?
Does anyone have any information or tips on porting from Compuware’s
DriverWorks to KMDF? We’ve finally released version 1 of the our
product, so we’re probably going to do our port away from DriverWorks
very soon. I’ve starting reading the WMD to KMDF guide, but I was
wondering if anyone has any more specific advice.
Thanks!
Michael Kohne
xxxxx@kohne.org
“You must be smarter than the equipment you are trying to operate.”
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
MICHAEL:
I can’t say that I know a great deal about KMDF in practice, but, based
on past responses to questions of anything SoftICE/DriverWorks on these
lists, I’m probably one of the very few members who has used both or at
least admits to it and is willing to comment beyond saying don’t use the
later. So, for what it is worth, in my opinion:
They really don’t have all that much in common.
You almost certainly (considering the base classes) use some very
nonstandard stuff in DriverWorks (like, say, Destructors (in particular
virtual ones)) that will require custom C++ RT support, to implement at
all.
DriverWorks hasn’t, to the best of my knowledge, been updated in
years. In particular, if you use DriverNetworks, the whole underlying
model (TDI) is being phased out. It is probably going to require some
support that KMDF intentionally does not provide.
I can’t recall what sort of support DriverWorks provides for PNP
and Power. If it does provide any, and you use it, porting that to KMDF
would negate one of the biggest reasons to use KMDF.
Most fundamentally, I think you would have to port/create a great
deal of a basic framework before you could really port anything of
yours, and debugging this would be pretty terrible, as there probably
would not be many sequence points until you had a great deal of
supporting code.
In my mind, if you source tree isn’t too large, I wouldn’t even
consider porting the parts of DriverWorks you would require to get
running, because it will definitely take longer, and DriverWorks has
some well know quirks, some of which are due to basic assumptions in the
design that may or may not be expressable in KMDF without violating its
own set. If your code base is large, then I really don’t know what I
would do, but I still can’t imagine that you would come out ahead by
doing this.
mm
>> xxxxx@kohne.org 2006-11-06 12:07 >>>
Does anyone have any information or tips on porting from Compuware’s
DriverWorks to KMDF? We’ve finally released version 1 of the our
product, so we’re probably going to do our port away from DriverWorks
very soon. I’ve starting reading the WMD to KMDF guide, but I was
wondering if anyone has any more specific advice.
Thanks!
Michael Kohne
xxxxx@kohne.org
“You must be smarter than the equipment you are trying to operate.”
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
OK. My thought, as I’ve been reading the WDM to KMDF porting guide is that KMDF provides most of the same stuff that DriverWorks does, just in a different form. Since I never got heavily into using the more esoteric features of DriverWorks (None of my objects, for instance, have virtual anything, I use no STL, and the couple of containers I have could easily be re-done as an interlocked list, and I did my DMA with DDK calls, not through the Driverworks objects), it shouldn’t be too much of a problem to do the conversion.
Frankly, I’m somewhat sorry I ever used DriverWorks. At the time (just when KMDF was first released) it looked like a good bet because it was older than KMDF, and I’ve learned to be very wary of 1.0 releases of anything from Microsoft. Since Compuware dumped the product, however, I obviously can’t afford to stick with it.
Oh well, at least MS decided not to charge for KMDF. That’s a nice plus on selling this to my boss.
Thanks!
Michael Kohne
xxxxx@kohne.org
“You must be smarter than the equipment you are trying to operate.”
-------Original Message-------
From: Roddy, Mark
> Subject: RE: [ntdev] Compuware DriverWorks to KMDF porting information?
> Sent: Nov 06 '06 13:30
>
> Scrap all the crap around your device specific code and start from
> scratch with KMDF. You should be able to salvage general algorithms and
> device specific operations, other than that not much else is going to be
> the same. That said, depending on what you are doing, in general a
> from-scratch KMDF prototype is a one or two week task. Don’t worry about
> conversion. Scrap that puppy and move on.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Michael Kohne
> Sent: Monday, November 06, 2006 12:08 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Compuware DriverWorks to KMDF porting information?
>
> Does anyone have any information or tips on porting from Compuware’s
> DriverWorks to KMDF? We’ve finally released version 1 of the our
> product, so we’re probably going to do our port away from DriverWorks
> very soon. I’ve starting reading the WMD to KMDF guide, but I was
> wondering if anyone has any more specific advice.
>
> Thanks!
>
>
> Michael Kohne
> xxxxx@kohne.org
> “You must be smarter than the equipment you are trying to operate.”
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
I’m sorry, I never ment to imply that I would port any part of DriverWorks over to KMDF to support my code. When I said ‘port’, I meant ‘change my code to use KMDF instead of DriverWorks’. In practice this certainly means ‘Start a new KMDF driver and grab any useful chunks out of the old driver’. I was just looking for any guidance anyone had as to equivalent structures in the two. My reading of the WDM to KMDF porting guide is giving me sufficient guidance, I think.
Interestingly, I think that DriverWorks and KMDF have a lot in common at the ‘idea’ level - they are both frameworks that handle most of the really nasty, annoying details for you (like tracking PnP and power states), letting you write your driver, not a bunch of standard boilerplate. I think that’s why Compuware got out of the buisness - DriverWorks is in C++ (definitely not recommended) and has some serious wierdness (just try to use WMILIB directly with DriverWorks. You’ll find that DriverWorks replicates some structures from wmilib.h in it’s own headers.). The fact that KMDF is supported and endoresed by MS just makes it’s use a no-brainer now that it’s past the 1.0 stage.
Michael Kohne
xxxxx@kohne.org
“You must be smarter than the equipment you are trying to operate.”
-------Original Message-------
From: Martin O’Brien
> Subject: Re: [ntdev] Compuware DriverWorks to KMDF porting information?
> Sent: Nov 06 '06 13:31
>
> MICHAEL:
>
> I can’t say that I know a great deal about KMDF in practice, but, based
> on past responses to questions of anything SoftICE/DriverWorks on these
> lists, I’m probably one of the very few members who has used both or at
> least admits to it and is willing to comment beyond saying don’t use the
> later. So, for what it is worth, in my opinion:
>
> 1. They really don’t have all that much in common.
> 2. You almost certainly (considering the base classes) use some very
> nonstandard stuff in DriverWorks (like, say, Destructors (in particular
> virtual ones)) that will require custom C++ RT support, to implement at
> all.
> 3. DriverWorks hasn’t, to the best of my knowledge, been updated in
> years. In particular, if you use DriverNetworks, the whole underlying
> model (TDI) is being phased out. It is probably going to require some
> support that KMDF intentionally does not provide.
> 4. I can’t recall what sort of support DriverWorks provides for PNP
> and Power. If it does provide any, and you use it, porting that to KMDF
> would negate one of the biggest reasons to use KMDF.
>
> 5. Most fundamentally, I think you would have to port/create a great
> deal of a basic framework before you could really port anything of
> yours, and debugging this would be pretty terrible, as there probably
> would not be many sequence points until you had a great deal of
> supporting code.
>
> 6. In my mind, if you source tree isn’t too large, I wouldn’t even
> consider porting the parts of DriverWorks you would require to get
> running, because it will definitely take longer, and DriverWorks has
> some well know quirks, some of which are due to basic assumptions in the
> design that may or may not be expressable in KMDF without violating its
> own set. If your code base is large, then I really don’t know what I
> would do, but I still can’t imagine that you would come out ahead by
> doing this.
>
>
> mm
>
> >>> xxxxx@kohne.org 2006-11-06 12:07 >>>
> Does anyone have any information or tips on porting from Compuware’s
> DriverWorks to KMDF? We’ve finally released version 1 of the our
> product, so we’re probably going to do our port away from DriverWorks
> very soon. I’ve starting reading the WMD to KMDF guide, but I was
> wondering if anyone has any more specific advice.
>
> Thanks!
>
>
> Michael Kohne
> xxxxx@kohne.org
> “You must be smarter than the equipment you are trying to operate.”
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>