WinDrvr : WinHEC

Fixing WinHEC - Part 2

DonBurn — Sat, 16 Feb 2008 14:17:00 GMT

In my last posting, I presented how to fix WinHEC from the attendee's point of view. This post will look at why it is critical for Microsoft to get it right. For the last 10 years, the Windows group has been waging a war to improve driver quality. In that time, many great tools and initiatives have aided the development of better drivers. But there are still a lot missing items, and unfortunately, Redmond seems disconnected from some of the problems of the driver community. Yes, a number of us try to call this out, but even the most respected professional will not carry the impact of a room with over a hundred driver developers saying "This tool or program has a problem".

Right now, I cannot think of an effort from Redmond that does not need some improvement, but when I talk to Microsoft developers, many of them do not believe the problems are important. The problems can range from the breaking of most corporate (and many personal) driver build environments by the incompatible changes to the setenv script, to complexity of Driver Test Manager. Worse yet, some efforts that were initially praised by the community are now despised. Take WPP tracing, for example: almost everyone viewed this as a fantastic tool when it came out, but with incompatible revisions and inability of most of the community to get the more advanced features to work, developers are now ripping the traces out of their drivers.

Redmond seems to be charging ahead with new programs and tools, many which appear good, but actually miss the mark terribly. It was revealed on the Microsoft newsgroups recently that they are working on Visual Studio integration for device driver development. While the community talks about this a lot, at last year's WinHEC, when the question was asked (in the one feedback forum that was held), most people rated this extremely low when compared to other tools and fixes to the existing tools.

Microsoft, you need to get the input of the community. Surveys such as the recent DTM survey are worthless, since they structure the answers into preconceived categories and do not allow the community to interact with each other and Microsoft. The great strength of Windows is the large number, and for most part, good quality of drivers available. Please don't waste your time on efforts without getting the community involved early on.

So, let's see a WinHEC that is exciting enough to attract a large audience, and filled with feedback sessions attended by Microsoft developers and managers to hear about the problems the community needs fixed.

Fixing WinHEC

DonBurn — Fri, 18 Jan 2008 21:11:00 GMT

As anyone who has been to WinHEC over the years knows, its content swings between being a heavy technical conference and being a marketing conference. This year’s WinHEC is scheduled for November 4-7, 2008, again in Los Angeles, California. I do not expect much from this venue, since neither of the two WinHEC’s previously in LA had a strong technical presence. Going to LA requires putting engineers on airplanes and into hotel rooms and not just for a few hours in a Seattle conference center.

So what makes a great techie WinHEC?

1. Lots of technical presentations – Some of the best conferences limited the keynotes to two. Good WinHEC’s offer repeats of talks and go until late the last day to allow people to get as much as possible.

2. Ask the Experts – Starting in 2001, Microsoft added Ask the Experts, where presenters were available after their talks to take questions. Sometimes this was in a separate room, sometimes this was over lunch. Personally, I like a separate room for an hour or so at each lunch break.

3. Birds of a Feather – For a number of years, there were Birds of a Feather (BOF) sessions where, for example, driver developers could comment on any topic to the WDK team. Sometimes there was a direction provided by Microsoft; much of the feedback for WDF came in BOF’s, but mostly BOF’s were wide open.

4. Developer Lounge – Unfortunately, this only happened one year in Seattle. This was a quiet location near the trade show entrance where you could find many Microsoft developers hanging out. It was a great place to drop by and ask a question, and had the advantage of allowing people to make the conversation fairly private when needed (versus the wide open Ask the Experts).

Last year’s WinHEC did not do a good job: it had five keynotes, and shut down early giving techies only 12 hours of presentations, versus as many as 21 some years. There were no Ask the Experts, or BOF’s, or a developer lounge. Unfortunately, there is no sign this will change in 2008. Much of the problem is that it seems that Microsoft figures that WinHEC’s don’t need to be techie when they do not have a lot of new technology to present.

It is time for the techies to take back WinHEC. After all, it is supposed to be an engineering conference. It should be easy to add back the Ask the Experts, BOF’s and a developer lounge. On the technical side, there is nothing wrong with their presenting new things, but I believe most of the community would also be interested in some deep drill-downs on existing technologies. As a bonus, being able to give input for improvement on existing technologies could improve the quality of drivers for all of us.

For deep drill-downs, may I suggest we have multi-hour looks at subsystems like the memory manager and the I/O manager? How about having feedback discussions for some of the technologies that do not thrill developers, for instance DTM, WPP/ETW and the lack of support for things that cause some dev’s to hook?

Come on Microsoft, last year’s WinHEC was poorly attended and technically boring. The above suggestions on information to present touches on just a few items, and I am sure the developer community can add many more. There are plenty of topics that would excite developers and make the conference the event the place to be. But, without a change in direction, I think most of us in the driver community will stay away from “Los Angeles, the land of fruits, nuts and lousy conferences”

Bleeding edge and far from it

DonBurn — Sun, 20 May 2007 17:36:00 GMT

I am just back from WinHEC and while there I realized that many people including a number from Microsoft don’t distinguish developing for the leading edge from living there. I am known as a guy who has done a number of things that Redmond had said “Windows is not capable of doing” and technologies that Microsoft was later proud to show off once they were working.

When it comes to my tools, I am far from the bleeding edge. For instance, though I recently started using the latest Visual Studio, most of my work is still done with VS6. I like the new Studio, but I trust VS6 and that version produces code that for the most part needs no libraries other than the standard system lib’s to support it. I use Office XP and probably will not move for a long time, since I once had a terrible experience of not being able to send a customer a promised document, since the conversion back to the format the client was using did not work well.

I am not alone in this attitude; many of the developers I respect the most stay far away from the leading edge for their work environments. In this way we are like Seymour Cray, who required that the parts for his designs were in production and testable even though the systems he was designing were years off.

The challenge here is that Microsoft does not seem to understand this. The WDK team was proudly pointing out the features and fast updates with online MSDN, when most developers use the local documents. One of the new features with the MSDN stuff is a wiki capability that is supposed to be monitored by using an RSS feed. Most of the senior developers I know do not monitor this, since Microsoft’s previous generation of tools do not support RSS! Another RSS problem is that when Microsoft “improved” its blogging site, it dropped email notification of blog postings, because RSS was available in all the brand new tools.

Another example from WinHEC was the Windows Driver Testing Framework. This tool assumes you are using the latest Visual Studio to develop with managed languages using the full strength of COM. I know of almost no respected driver writers who know how to do this, and even fewer who would want to.

It has to be confusing for the WDK team because their core product is the exception that proves the rule. Over the years, the development community has found that BETA and just released versions of the DDK are excellent so we trust using these in our day to day work. Unfortunately, few other teams in Redmond inspire this confidence.

So, Microsoft, if you want us to keep developing on the bleeding edge, give us tools that do not force us to live there.

Never stop learning

DonBurn — Tue, 01 May 2007 20:08:00 GMT

One thing I always recommend to my customers is to keep their developers up to speed on the latest Windows driver technologies. I’m thinking about this right now, since last week saw the release of Developing Drivers with Windows Driver Foundation and we are less than two weeks away from the start of this year’s WinHEC.

It is scary how many managers and developers believe that they don’t need to know this new stuff. Even if you are still required to do drivers for NT 4.0 (hopefully not), learning the new stuff can improve your code. Just seeing where Microsoft has put its effort to improve things may suggest to you places in your code you need to review and improve.

Also, just because you can’t use the latest Windows versions does not mean you cannot use the latest tools. I had a customer a few years ago who had been chasing a bug for around six months. I used PREfast on the code and found the bug in the legacy driver in a couple of minutes!

Yes, you can in theory learn this stuff from the Windows Driver Kit documentation, but that is the hard way to do it. There are a lot of great papers on Windows Driver and Hardware Central and at OSR Online . I check them weekly to see what is new. The challenge for papers and documentation is to know how to approach all the information. That is where a book, WinHEC, or one of the excellent classes offered on Windows drivers can help.

This year will be my 10^th WinHEC, and at every one of them I have learned something new that I now apply to my work. More importantly, WinHEC is a chance to meet many of the experts in the field. You don’t want to abuse this, but it is extremely useful to be able to drop an email to an expert and ask a question.

People ask on forums, “What book should I get to learn device drivers? “ The real answer is, all of them. Looking up at my bookshelf, I see 17 books on Windows internals and drivers, including each version of some books. This does not count all the class notes, the booklets from WinHEC, and many years of OSR’s NT Insider. It also does not count the draft of the excellent WDF book I mentioned in the first paragraph. I was a technical reviewer of the book and cannot wait to get my hands on the production version.

I’ve been writing drivers and system software for 35 years, and it surprises some of my clients when I mention I’ve taken five classes on Windows driver development. These clients think if you’ve written drivers before, you only have to tweak what you know. Nope. Windows is an incredibly rich development environment for drivers, and there is a lot to learn. Right now if I had the time, I would like to sign up for a couple of classes from OSR and a couple from Azius, about Windows driver development, because there are areas I know I could learn more about.

Never stop the learning process for yourself or your developers. If you do, you are crippling your product’s capabilities and/or time to market, and your future employability as a developer.