Hi all,
??? I am new to kernal mode programing.I want to study about it in deep.Which is the good way to study?.please tell me some tutorials and site about it. My target date is very tight.So please help me.
??? Thanks to all
Try the new Yahoo! India Homepage. Click here. http://in.yahoo.com/trynew
Windows KM programing is very vast, It depends on which technology you want
to write/design the driver?? Audio OR File system OR USB,
On Mon, Oct 12, 2009 at 12:52 PM, Sree K wrote:
> Hi all,
> I am new to kernal mode programing.I want to study about it in
> deep.Which is the good way to study?.please tell me some tutorials and site
> about it. My target date is very tight.So please help me.
> Thanks to all
>
> ------------------------------
> Connect more, do more and share more with Yahoo! India Mail. Learn morehttp:</http:>.
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Hi Sree,
I am in the same situation… What helped me to get a little bit into wdf were 2 things: an existing driver with sourcecode with a real device ‘to play’ and a book. Bringing ddk to work, entering some new log messages, bringing windbg to run and seeing when which function is called when brings a lot of learning effect for the basics.
There are some learning-devices from OSR, maybe you could consider one of these to start. I started with a PCI demo card (DM648-DSP Eval board) and a driver for it (with sourcecode) from Sheldon Instruments. I have bought the WDF book from Orwick/Smith (MS-Press) that is a good starting point from my point of view, even though you have to read some chapters twice… You’ll find a lot of information online, but at least part of that is confusing half-truth information. I found this forum really helpful. There are some of the ‘big guys’ around (mentioned in the MS-Press book…) answering your questions. I didnt find a lot of tutorials online. It seems to me that most of the guys that have digged into driver programming keep their knowledge form themselfs.
From my point of view the best way to get started is to get a good book, a real device with an existing driver (sourcecode incl.) and a real problem.
bye,
Thomas
Hello Sree,
I’d like to caution you against jumping in and releasing a driver without truly taking the time to develop the skillset. In particular, this part of your posting concerns me.
My target date is very tight.So please help me.
I’ve seen very many lousy/unstable drivers released by programmers who had driver development thrust upon them because their managers didn’t fully understand the realities of driver writing. Not everyone grasps that specialized training/skills are required when the stability of the operating system is in the hands of their programmers. The creation of drivers for a product (hardware or software) is often treated as an after-thought, and we all suffer when that happens.
So, Sree, would you please do your best to make sure that your team/company does not force you into driver development until you’ve been properly trained and your driver design/coding/debugging/validation skills have properly developed? The amount of time invested at this stage will likely have a significant impact on the success of your product down the road.
I would definitely recommend that you take a driver training class given by qualified driver-writing professionals (such as OSR). Because of the complicated subject matter, having a professional trainer is often the only way you’ll be exposed to the undocumented “gotcha’s” before it’s too late to prevent them from affecting your customers.
Thanks. And best of luck! 
– Keith
I’d like to add a bit to what Keith said. In fact, I need to write an article about this for The NT Insider.
The way most of us extend our programming knowledge these days is to get a sample that does SOMEthing like what we need done and hack on it until it does what we need. In general, we don’t need to understand how the whole program works… we just need to understand bits of the program at a time, starting with the bits the we need to modify.
This approach works pretty well for things like, say, C# .NET – You download an example from CodeProject or whatever, you don’t need to understand the whole thing and in fact you can ignore about 90% of it because it’s working. You just focus on a few items… how a given control is handled or whatever… and iteratively hack the code, with copious use of Google and other examples, and you make it work.
The problem is that in the world of driver development this approach almost never works.
Why not? Four reasons:
a) Solutions to different problems can be VERY different. Even though two problems might seem similar to a new driver dev, these two problems might require very different architectural solutions to function properly. This makes is horrendously difficult to choose a good example to start with.
b) There’s a lot of “stuff” you need to know before you can do anything productive with a driver. While WDF reduces this amount of “stuff” a lot (by a factor of magnitude at least) there are still a lot of basic concepts that many non-kernel devs aren’t familiar with and that you can’t ignore (such as IRQLs, interrupts, D-States, and the like).
c) What REALLY matters when you write a driver is knowledge of the hardware you’re controlling and how it will be used. This drives (ha! Pun intended) just about all the decisions in your driver, and this is almost certainly where you’ll wind-up spending the vast majority of your debugging/development time. It’s natural when getting started with driver development to focus on the interfaces between the OS and the driver. But once you learn about these things, the job really is about how you want your device to work. Many folks coming to the world of driver development come with experience from the software side (as opposed to the device side) and overlook this fact. Thus, it won’t necessarily be obvious to a new driver dev if the policies (for power, or PnP, or request handling) implemented by a given example driver are reasonable or applicable to another device.
d) There aren’t NEARLY as many examples of driver-development related code online as there are user-mode code. You can Google just about ANYthing about C# .NET and come up with code fragments that can be cut/pasted to work in an application. This just isn’t so for driver development… there are far fewer people (probably two or three factors of magnitude fewer) working in the kernel space than in user land. And many of the driver examples online outright suck.
Sadly, the only effective way to learn driver development is the “old way”… sit down with your books and study first. It’s can be slow, and it lacks immediate gratification. But it turns out to be relatively efficient in the end (it’ll save a ton of time versus chasing down problems the parameters of which you don’t really understand).
Hope this helps,
Peter
OSR