Developer Explains Why All Windows Drivers Are Dated June 21, 2006 (microsoft.com)

For years, people have wondered why all Windows drivers are dated June 21, 2006. Long time developer at Microsoft, Raymond Chen explains (much of the entire post in summary): When the system looks for a driver to use for a particular piece of hardware, it ranks them according to various criteria. If a driver provides a perfect match to the hardware ID, then it becomes a top candidate. And if more than one driver provides a perfect match, then the one with the most recent timestamp is chosen. If there is still a tie, then the one with the highest file version number is chosen. Suppose that the timestamp on the driver matched the build release date. And suppose you had a custom driver provided by the manufacturer. When you installed a new build, the driver provided by Windows will have a newer timestamp than the one provided by the manufacturer. Result: When you install a new build, all your manufacturer-provided drivers get replaced by the Windows drivers. Oops. Intentionally backdating the drivers avoids this problem. It means that if you have a custom manufacturer-provided driver, it will retain priority over the Windows-provided driver. On the other hand, if your existing driver was the Windows-provided driver from an earlier build, then the third-level selection rule will choose the one with the higher version number, which is the one from the more recent build. It all works out in the end, but it does look a bit funny.

Comments

Put the real date in the info area!

[Joe_Dragon]

Put the real date in the info area!

A bit here a bit there

[goombah99]

Right. A bit here a bit there and pretty soon you have saved a whole byte. Overloading the date value with multiple meanings is so 1980s programming. Maybe they could also start using special dates for other meanings too! that way they could save another bit somewheres

Typical Microsoft kludge

[OneSmartFellow]

So, if the hardware provider creates a driver too, why does MS use the "perfect match hardware ID".. Why not a system where the manf. Hardware ID is X.Y.Z.Pref  (or some other identifier which would supersede the Microsoft version) and Microsoft's would then be X.Y.Z.Microsoft.  Then it's really obvious what's going on, it doesn't rely upon checking for date, or version ID, or other in-exact ways of *guessing* which driver to use.<br><br>
Why ?<br>
Because, the vast majority of devs at MS can't think straight about anything - that's why we have the current state of Windows.  MS hasn't hired a good developer since the days of Windows NT.

Programming the Windows Driver Model

[monkeyxpress]

I realise the driver system in windows has moved along (hopefully for the better) a lot recently, but about 15 years ago I remember looking into developing a custom driver for a USB device I had developed. My background was as an embedded developer so I had a detailed knowledge of how the bits on the bus worked, and what the host controller chip was doing. All I wanted to do was send some packets to my device and receive a few packets back from a windows application - nothing real time or taxing of the system's capabilities.

I got a copy of Walter Oney's windows driver model book, and proceeded to work my way through it.

Even now, as someone who does a fair amount of web development, working my way through ten years of terrible javascript language and library designs decisions to make otherwise simple things happen on a webpage, it still shocks me just how ridiculously horrible the WDM was. The basic IRP system was already pretty over the top architectural astronauty, but I guess you could accept that they had to provide for the possibility that there would be a lot of fancy new peripherals in the future. But once you figured that out, the book went into how incredibly broken the model was once you had to support multi-processor system and plug and play. What ensued was basically 200 pages describing the most horrible mess of obscure synchronisation problems you could possibly find in a couple of pages worth of driver code.

Ever since I ceased being shocked when my computer BSOD due to a third party driver. Frankly, if the thing allowed you to get much done at all, whoever wrote the driver probably deserved a medal or something.

Anyway, with such an experience, this back dating driver thing doesn't surprise me in the slightest.

Re:Programming the Windows Driver Model

[ShooterNeo]

I'm doing embedded work. I've noticed (and done myself) that there is a way to dodge this issue. What you do is, you stick an FTDI chip at the front end. USB to serial is the easiest, but if you need more bandwidth, you can do USB to SPI. So FTDI manages the drivers, and most windows (and Linux) PCs are going to have valid FTDI drivers in them from OS install. You then either access the chip by having it map to a comm port or there is a way to link to FTDI's drivers.

Either way, you export the problem - FTDI worries about writing and maintaining the driver, which hundreds of millions of devices depend on, and you just piggy back on that driver for your gadget. Works great and you can be up and running in under a day. (just use their USB to serial one, and connect RX and TX, and use the scanf/printf which most any microcontroller has support for)

Re:Wrong Priority

[ShooterNeo]

Yeah that's what I don't get. Why doesn't version number take precedence over time stamp? Why isn't the time stamp the date the manufacturer driver got Windows Certified? If you think about it, the last windows certified driver is going to be the one you want, from the perspective of an OS updater you want the latest version from the most stable branch.

Re:There's a word for this

[TheFakeTimCook]

There's a word for this method of solving a problem: it's a kluge.

Exactly what I came here to say.

Microsoft Developers have got to be the laziest on the planet. EVERYTHING that MS does is done for the ease of their Developers, regardless of what hoops or inconvenience it causes the User.