• <legend id="8xv0q" ></legend>
    <th id="8xv0q" ></th>
    <code id="8xv0q" ></code><b id="8xv0q" ></b>
    <rt id="8xv0q" ></rt>
        <pre id="8xv0q" ><li id="8xv0q" ></li></pre>
          <bdo id="8xv0q" ></bdo><big id="8xv0q" ><listing id="8xv0q" ></listing></big>

          <li id="8xv0q" ><acronym id="8xv0q" ></acronym></li>
          1. <nobr id="8xv0q" ><var id="8xv0q" ></var></nobr>

            <xmp id="8xv0q" >

            Blogging Again

            Tacoma-narrows-bridge-collapse

            A little over 7 years ago, I stopped blogging as my consulting practice took off. With a re-launch of my website I decided to return to blogging, but this time with a different focus. One thing I consistently do is answer questions on the newsgroups and forums covering Windows driver development. This blog will concentrate on common questions in developing device drivers, and in particular thoughts on creating high quality drivers.
            Quality is a very important part of windows driver development, so I figured I should check the latest materials. I was surprised to find that a web search placed high on the list my presentation and other papers from ten years ago! In fact there was almost nothing since the 2005 WinHEC conference on the subject.
            I started thinking about why we don’t talk about driver quality anymore, and I realized that there were a lot of reasons both good and bad that we don’t use the term quality. The good is that the quality of Windows drivers has improved, a lot of this is because of Microsoft’s efforts in things like Code Analysis (aka Prefast), Static Driver Verifier, the Windows Driver Framework, and better samples. The bad reasons, are in many way’s also related to the above tools, many developers think the tools take care of the problems.
            Even though drivers have significantly improved, there is still a lot further for them to go. Engineering bridges is an old and well established science yet we still have bridge collapses, computers are a little younger than the bridge collapse shown at the start of this post, and we still have a long ways to go.
            So, I decided to focus much of this blog about developing high quality Windows device drivers. A lot of this will still be about simple things for developing device drivers, because in actuality a lot of efforts related to quality are pretty simple, developers just get busy and don’t do them. I hope there will be a few new items, but much of this will just going over best practices.
            When I delivered the presentation above I got three kinds of responses:
            1. People liked it and it got them thinking about what they did or did not do.
            2. People complained “it was a repeat of Code Complete by Steve McConnell”, well yes you will find a lot of what I talk about in any good software development book. Of course it is still important to apply it, a few years later I reviewed a driver written by one of the complainers, who seemed to have forgotten everything from the book and the talk.
            3. People complained “I was expecting a new technique that solves all the driver quality issues”. Yes, I really heard this a few times, of course I suspect these people have made their millions through one of the many offers for money we get in the email ;-).
            If you are an experienced driver I hope you will ask yourself after reading one of these posts, Am I doing everything I can in the area the post was about to create quality drivers? If you are new to windows driver development, or a manager trying to understand what is going on, please look at these as guidance for your efforts.