Toolkits for developing drivers
-
I'm looking for some kind of toolkit used for building drivers. I know of two:
- Numega/Compuware DriverStudio
- Jungo WinDriver[^]
Compuware has retired DriverStudio since 2006 and I cannot find any replacement for it from Compuware. So building a driver for e.g. 64-bit Vista would be out of the question with an old version of DriverStudio. Is really Jungo the only alternative out there? Of course it's possible to build a driver with only the DDK, but I figure that the benefits of using a toolkit outweighs the drawbacks. Any tip is appreciated.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
I'm looking for some kind of toolkit used for building drivers. I know of two:
- Numega/Compuware DriverStudio
- Jungo WinDriver[^]
Compuware has retired DriverStudio since 2006 and I cannot find any replacement for it from Compuware. So building a driver for e.g. 64-bit Vista would be out of the question with an old version of DriverStudio. Is really Jungo the only alternative out there? Of course it's possible to build a driver with only the DDK, but I figure that the benefits of using a toolkit outweighs the drawbacks. Any tip is appreciated.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
Compuware has retired DriverStudio since 2006 and I cannot find any replacement for it from Compuware. So building a driver for e.g. 64-bit Vista would be out of the question with an old version of DriverStudio.
I only used DriverStudio in the past. To tell the truth, I don't really like it though: When there are more than one DDK version installed in the system, configuring VC6 for DriverStudio is sometimes a nightmare. And SoftICE debugger usually failed with most of newer graphic chips. The driver team of my company uses simply WDK without any helper toolkit. Even though DriverStudio is retired, there is DevPartner (LINK[^]) to replace with.
Maxwell Chen
-
Fat_Boy develops drivers for a living, drop him an e-mail via CP and ask him what he uses.
Mmm, that's a thought, but I'm rather reluctant to sending personal mails. I know I get somewhat upset when people are emailing me directly asking for help, it kind of invades the privacy... Well, that's how I interpret the forum guidelines and since that's how I would like to be treated, I treat other members the same way. But it's a good idea otherwise, thanks.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Roger Stoltz wrote:
Compuware has retired DriverStudio since 2006 and I cannot find any replacement for it from Compuware. So building a driver for e.g. 64-bit Vista would be out of the question with an old version of DriverStudio.
I only used DriverStudio in the past. To tell the truth, I don't really like it though: When there are more than one DDK version installed in the system, configuring VC6 for DriverStudio is sometimes a nightmare. And SoftICE debugger usually failed with most of newer graphic chips. The driver team of my company uses simply WDK without any helper toolkit. Even though DriverStudio is retired, there is DevPartner (LINK[^]) to replace with.
Maxwell Chen
Maxwell Chen wrote:
Even though DriverStudio is retired, there is DevPartner (LINK[^]) to replace with.
Well, Maxwell.... Perhaps I'd better get my eyes checked, but I cannot find any information saying that DevPartner can be used for developing drivers the same way DriverStudio was used. I've looked through the page you linked to prior to starting this thread, but to me DevPartner seems more like a tool for analysing the source code when it's already been written rather than using it for development with some class libraries. DevPartner could probably be used for debugging a device driver, but I expect a toolkit to be bundled with that functionality as well as a class library or similar to be used for creating the driver. Do you know of a page I haven't found that clearly stating that DevPartner ships with code and/or wizards to facilitate the development of a driver? :~
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Maxwell Chen wrote:
Even though DriverStudio is retired, there is DevPartner (LINK[^]) to replace with.
Well, Maxwell.... Perhaps I'd better get my eyes checked, but I cannot find any information saying that DevPartner can be used for developing drivers the same way DriverStudio was used. I've looked through the page you linked to prior to starting this thread, but to me DevPartner seems more like a tool for analysing the source code when it's already been written rather than using it for development with some class libraries. DevPartner could probably be used for debugging a device driver, but I expect a toolkit to be bundled with that functionality as well as a class library or similar to be used for creating the driver. Do you know of a page I haven't found that clearly stating that DevPartner ships with code and/or wizards to facilitate the development of a driver? :~
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownYou are right! DevPartner seems to focus on user mode analysis and debugging. There is no kernel mode device driver features. I am so sorry that I made a mistake.
Maxwell Chen
-
You are right! DevPartner seems to focus on user mode analysis and debugging. There is no kernel mode device driver features. I am so sorry that I made a mistake.
Maxwell Chen
Maxwell Chen wrote:
I am so sorry that I made a mistake.
No worries, Maxwell.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
I'm looking for some kind of toolkit used for building drivers. I know of two:
- Numega/Compuware DriverStudio
- Jungo WinDriver[^]
Compuware has retired DriverStudio since 2006 and I cannot find any replacement for it from Compuware. So building a driver for e.g. 64-bit Vista would be out of the question with an old version of DriverStudio. Is really Jungo the only alternative out there? Of course it's possible to build a driver with only the DDK, but I figure that the benefits of using a toolkit outweighs the drawbacks. Any tip is appreciated.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownThere is the KMDF from Microsoft. I used that for my latest drivers and found it relatively easy to use, if a bit verbose in its function names :) . It handles a lot of the tedious repetitive stuff like PnP and Power management for you. Now that KMDF is around, I haven't found a need to try to find another toolkit - the framework deals with all the stuff I previously wanted dealt with by a toolkit. Judy
-
There is the KMDF from Microsoft. I used that for my latest drivers and found it relatively easy to use, if a bit verbose in its function names :) . It handles a lot of the tedious repetitive stuff like PnP and Power management for you. Now that KMDF is around, I haven't found a need to try to find another toolkit - the framework deals with all the stuff I previously wanted dealt with by a toolkit. Judy
Nice Judy, thanks. I'll look into it.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
I'm looking for some kind of toolkit used for building drivers. I know of two:
- Numega/Compuware DriverStudio
- Jungo WinDriver[^]
Compuware has retired DriverStudio since 2006 and I cannot find any replacement for it from Compuware. So building a driver for e.g. 64-bit Vista would be out of the question with an old version of DriverStudio. Is really Jungo the only alternative out there? Of course it's possible to build a driver with only the DDK, but I figure that the benefits of using a toolkit outweighs the drawbacks. Any tip is appreciated.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
but I figure that the benefits of using a toolkit outweighs the drawbacks.
not really. wrappers like jungo have their uses, perhaps (although I would never use it), but eventually, you are going to have to get your handsa dirty and dig around beneath the wrapper to either fix something in the wrapper or get some functionality it doesnt provide. and then you are looking into the depths of hell itself. so you might as well start of like you mean to go on and take the big leap, dig into it, and just use the WDM api. The ddk is limited, confusing, and nightmarish to useso, provided you only want to do WDM, then I suggest Walter ONeys book, Programming the Windows Driver Model.
Morality is indistinguishable from social proscription
-
Roger Stoltz wrote:
but I figure that the benefits of using a toolkit outweighs the drawbacks.
not really. wrappers like jungo have their uses, perhaps (although I would never use it), but eventually, you are going to have to get your handsa dirty and dig around beneath the wrapper to either fix something in the wrapper or get some functionality it doesnt provide. and then you are looking into the depths of hell itself. so you might as well start of like you mean to go on and take the big leap, dig into it, and just use the WDM api. The ddk is limited, confusing, and nightmarish to useso, provided you only want to do WDM, then I suggest Walter ONeys book, Programming the Windows Driver Model.
Morality is indistinguishable from social proscription
Thanks for your reply fat_boy.
fat_boy wrote:
but eventually, you are going to have to get your handsa dirty and dig around beneath the wrapper to either fix something in the wrapper or get some functionality it doesnt provide.
So I shall interpret this as something like "if you're writing a simple driver you won't need a toolkit and if you're writing a complex driver a toolkit provides more trouble than help"? Or would that be pushing it too far? My customer needs a driver for USB DFU (Device Firmware Upgrade), but they need to be able to modify the driver after I've left the building. Even if I consider a driver for DFU as quite small and simple in comparison, my customer has very little or none experience of kernel mode development. That's why I'm interested in toolkits such as the one from Jungo as I assume that the need for kernel mode experience is limited (at least Jungo claims so). Other ideas or Suggestions?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Thanks for your reply fat_boy.
fat_boy wrote:
but eventually, you are going to have to get your handsa dirty and dig around beneath the wrapper to either fix something in the wrapper or get some functionality it doesnt provide.
So I shall interpret this as something like "if you're writing a simple driver you won't need a toolkit and if you're writing a complex driver a toolkit provides more trouble than help"? Or would that be pushing it too far? My customer needs a driver for USB DFU (Device Firmware Upgrade), but they need to be able to modify the driver after I've left the building. Even if I consider a driver for DFU as quite small and simple in comparison, my customer has very little or none experience of kernel mode development. That's why I'm interested in toolkits such as the one from Jungo as I assume that the need for kernel mode experience is limited (at least Jungo claims so). Other ideas or Suggestions?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownWriting kernel drivers for windows is a serious undertaking regardless of the size: every driver has the potential to trash the OS so I would not expect anyone short of a very good Windows programmer with 5 years of experience capable of even starting to begin to modify a driver and have it anywhere near stable. And even then they will have a massive learning curve. I dont know Jungo though and it might well do what you want. Talk to them and see.
Morality is indistinguishable from social proscription
-
Thanks for your reply fat_boy.
fat_boy wrote:
but eventually, you are going to have to get your handsa dirty and dig around beneath the wrapper to either fix something in the wrapper or get some functionality it doesnt provide.
So I shall interpret this as something like "if you're writing a simple driver you won't need a toolkit and if you're writing a complex driver a toolkit provides more trouble than help"? Or would that be pushing it too far? My customer needs a driver for USB DFU (Device Firmware Upgrade), but they need to be able to modify the driver after I've left the building. Even if I consider a driver for DFU as quite small and simple in comparison, my customer has very little or none experience of kernel mode development. That's why I'm interested in toolkits such as the one from Jungo as I assume that the need for kernel mode experience is limited (at least Jungo claims so). Other ideas or Suggestions?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownSince this is a USB device, perhaps the User-Mode Driver Framework[^] would be appropriate? See the FAQ[^].
DoEvents: Generating unexpected recursion since 1991
-
Writing kernel drivers for windows is a serious undertaking regardless of the size: every driver has the potential to trash the OS so I would not expect anyone short of a very good Windows programmer with 5 years of experience capable of even starting to begin to modify a driver and have it anywhere near stable. And even then they will have a massive learning curve. I dont know Jungo though and it might well do what you want. Talk to them and see.
Morality is indistinguishable from social proscription
fat_boy wrote:
every driver has the potential to trash the OS so I would not expect anyone short of a very good Windows programmer with 5 years of experience capable of even starting to begin to modify a driver and have it anywhere near stable. And even then they will have a massive learning curve.
Exactly my point. That's why I wanted something to simplify things for my customer, if they need to modify the driver in the future. Perhaps the chances of combining these two parameters are ridiculously close to zero and I end up writing it with the DDK anyway, or one of the frameworks Judy and Mike has suggested. On the other hand it may create an opportunity to return to the scene of the crime if the driver needs to be modified. Thanks for your time fat_boy.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Since this is a USB device, perhaps the User-Mode Driver Framework[^] would be appropriate? See the FAQ[^].
DoEvents: Generating unexpected recursion since 1991
It may be. Judy suggested me to look into both UMDF and KMDF and I've done so a little. I haven't had the time to really get into things yet, but I will certainly have a serious go for it. Judging from the FAQ it will do very well for this DFU driver. I haven't really found all the info I need on how to get the framework and what it costs and that's essential input for my customer to make a decision whether to use it or not. As I understood it, the framework is available through this MS "Connect"-thing... But what's the charge? Got to ask since I couldn't find a statement that it's free of charge. Any chance you know it by heart?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
fat_boy wrote:
every driver has the potential to trash the OS so I would not expect anyone short of a very good Windows programmer with 5 years of experience capable of even starting to begin to modify a driver and have it anywhere near stable. And even then they will have a massive learning curve.
Exactly my point. That's why I wanted something to simplify things for my customer, if they need to modify the driver in the future. Perhaps the chances of combining these two parameters are ridiculously close to zero and I end up writing it with the DDK anyway, or one of the frameworks Judy and Mike has suggested. On the other hand it may create an opportunity to return to the scene of the crime if the driver needs to be modified. Thanks for your time fat_boy.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
On the other hand it may create an opportunity to return to the scene of the crime if the driver needs to be modified.
That is a good idea. Sell them the product and maintenance. If you ever do get a driver up and running, well, you will have acchievde a massive amount. You can capitolise on that work.
Morality is indistinguishable from social proscription