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.
Change all the dates of your co-worker's drivers. Set them to the future.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Why don't they simply add another record ("source") to help make the driver comparison? A typical Microsoft solution I would say.
. Maybe it's all the weed talking, but I've really lost the will to even attempt to understand all the insane complexity of modern PCs. I feel like I do nothing but constantly deal with all sorts of bizarre glitches and software harassing me in numerous ways, to the point where I mostly use the computer for the sake of maintaining itself, rather than any actual work.
That's not how it was back in the Amiga days.
Seems like a really badly designed system to me. If the time stamp of a driver somehow got changed by accident, it would lead to a very hard to find problem.
Put the real date in the info area!
This is the type of hack that an inter is chastised for in a code review.
Ship it.
I am very small, utmostly microscopic.
Why were there all the issues with Windows 10 replacing manufacture drivers with Microsoft ones then? I am guessing they have since fixed that, but I did hear about a lot of complaints.
"He's lost in a 'floyd hole"
There's a word for this method of solving a problem: it's a kluge.
http://www.geoffreylandis.com
Seems to me that MS found a bug that their latest build screwed up the 3rd party driver, so they came up with a short-term fix for it. Then they never ever worked on a long term solution because nobody (or not that many people) complained.
nm
Is it just my observation, or are there way too many stupid people in the world?
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
Some drink at the fountain of knowledge. Others just gargle.
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.
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.
Um.. since most drivers are now signed/certified would the signature not have better info than a fucking date stamp to determine age/version/author/priority? By default windows requires signed drivers, so what gives? I am not a coder by day but this seems kludgy as shit.
Silence is a state of mime.
Prefix all their drivers with AARDVARK_
I had a dream, bright and carefree, but now there's doubt and gravity
It's plain ugly.
Perhaps using a higher revision number before a newer time stamp would be the way to solve this stupidity.
"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." But is it the flagon with the dragon or vessel with the pestle?
Care killed the cat, but satisfaction brought it back.
I was expecting an answer to why that particular date was chosen. I could easily have guessed that they were back dated to allow files with new filestamps to take priority. But why that date, and not, say, 1970-01-01 00:00:00?
For years, people have wondered why all Windows drivers are dated June 21, 2006.
Yup, I just checked. All my XP and Vista drivers are dated 7/21/2006. How did they know?
Chaos maximizes locally around me.
I think we already knew this type of bullshit was happening under the hood but it's nice to see a detailed explanation. Gross though.
Twinstiq, game news
why no one takes Microsoft seriously. I mean how hard is it to maintain a "registry" of drivers for a given device? It's not like peripherals don't have unique ids you can get at through the bus.
It's Windows, so, they probably do something nutty like compute epoch time as an offset from 2006. Since 1970 would be a negative number, some deep and dark timestamp code somewhere in the driver model probably (correctly) assumes the timestamp is unsigned so, 1970 is actually far into the future.
. Maybe it's all the weed talking, but I've really lost the will to even attempt to understand all the insane complexity of modern PCs. I feel like I do nothing but constantly deal with all sorts of bizarre glitches and software harassing me in numerous ways, to the point where I mostly use the computer for the sake of maintaining itself, rather than any actual work.
That's not how it was back in the Amiga days.
You need to shitcan that Linux box and buy a Mac.
Microsoft version's their drivers with the Windows version (5.1.2600), ATI's Drivers at the time were something like Catalyst 2.6. If they used the version number, Microsoft's drivers would have always been higher.
They're working under the paradigm of the Windows Installer engine, and using the behaviour that it provides to get the behaviour they want without changing the engine.
If they added new "Microsoft driver vs. Manufacturer Driver" logic to a new version of MSI, installation programs built with an older version wouldn't be able to use it, and if MS forced it to apply to installations built with an older schema, they could break the manufacturer's intended behaviour.
This date thing follows all the MSI rules as they exist, wont' cause any unintended behaviour, and by using the Windows Vista RTM date, they guarantee that they will replace any pre VISTA drivers, but drivers that have been updated by the manufacturer will always take precedence.
If they made another major driver model change, they would probably change their drivers to that new date, to cause the same behaviour again.
It sounds like the date is almost never, ever, used as they are all dated the same. Why even consult that field or have it exist at all?
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
We're talking about default behavior here. Obviously if the user wants to override that and install any (signed) driver they want, they can do it. If they want install an unsigned driver, these days they are forced to reboot into safe mode, which I don't disagree with, since drivers have the privileges to do almost anything and the user has no way to know what a driver will do from the binary.
1970 is the epoch for Unix, 1980 for DOS, because Microsoft is always ten years behind Unix.
Windows actually has a shitload of different epochs. Some of their filesystems use 1980, some use 1601
1980, Excel uses January 0, 1900, some versions of their compiler use 12-30-1899, COM uses 12-31-1899. It's a real cluster fuck.
... a massive kludge to get around yet another Windows design flaw.
1. Watch Silicon Valley. 2. Note jaw droppingly bizarre tech 'splaining by Erlich Bachman (and other selected characters). 3. Note similarity to Windows driver decision tree explanation. Or not.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
... that so long as there is an explanation n for the incredibly stupid design decision, that design decision is masterful.
As the driver system architect you have to:
Make sure all the existing drivers work
Work with every possible permutation of system - multi core, weird combinations of peripherals
Anticipate new possibilities even though you have no idea what those might be
Get it done by a deadline
No you don't get to go back and fix past mistakes, you don't get to create a new preference field, you have to work with something that is common to every existing driver. Kludge? It's ugly but I bet 99.9% of us couldn't have come up with something better and MS just didn't have the 0.1% guy available at the time.
...you had to use a hacky, counterintuitive fix to cover for a bad design decision. Business as usual at Microsoft, in other words.
Actually his box was Windows.
That is why things are so complicated.
Hold on. Let's say that a virus modifies the older driver which, of course, now bumps the timestamp to the day of the infection. This would move the older - now infected - driver up in the priority? Wow. That explains so much.
As Raymond Chen would say, "That rather involved being on the other side of the airtight hatchway". If you can modify the driver, who cares about the timestamp, just modify the actual driver being used and be done with it.
But device drivers, especially printer drivers were the front lines of the war between MS-Word and WordPerfect in 1990s. WordPerfect created a virtual printer to which its software will print. They laboriously wrote printer drivers for every printer maker in existence at that time. In those days no matter how obscure and unknown your printer is, WordPerfect will be able to correctly print in it. It also got the "exactly the same printout, no matter what the printer is" edge over Microsoft.
One way MS decided to create Windows printer driver standard and strong armed all the printer makers to supply a driver that will meet the windows spec. Apple Laserwriter and most other unixy printers had settled on postscript. It wanted to mess them up too. So it was all serious market share battleground those days. Forcing a proprietary ill-defined ever changing driver spec was MS way to deny the competitive advantage WP had built laboriously.
But it also created two serious side effects on MS-Word. They comingled the virtual device driver code into MS-Word and tried to get the WYSIWYG cheap way. That is why MS-Word margins would change, pagination would change and page references would change if you change your default printer. It was a nightmare those days. Grad students who were PhDs in Engineering went completely bonkers trying to get a paper correctly printed in MS-Word, and worse the TeX guys were laughing at them.
The second effect was hard pressed printer makers hacked out really bad printer drivers. Many of them took some approximate driver from some place and hacked out something that barely worked and passed basic acceptance test. Then bug reports would pour in, they will fix some of them, then post updated drivers... the mess has not been fully sorted out even now.
The damage Microsoft did by deliberately sabotaging inter-operability is incalculable.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Hey, it sounds like you have a deployment problem. Just use docker and kubernetes to keep your system up to date and everything will be easy. J/K docker is a mess, the problem is it's too close to the metal and needs to abstract some of those differences away. It should really have been built on top of systemd. Clean, simple, easy. You can run the deployment server in your bios.
"First they came for the slanderers and i said nothing."
It is interesting to see this is complete opposite of what we have on Linux. Here, vendor drivers are almost universally shitty. If they work at all, vendors tend to ship drivers compiled for ancient and/or specific kernels.
On Linux, if you have driver in kernel, you almost always want it instead of vendor provided one. nVidia GPU driver may be the only exception.
:wq
UEFI doesn't suffer the same addressing limitations BIOS does. Just put the vendor driver in the hardware firmware, perhaps on EEPROM.
Or, as some people spell the word, a kludge.
Also known as literate people.
So, some random site decided to grab the URL of "oxford dictionaries", I assume to mislead people into thinking that this is the Oxford English Dictionary
Don't slashdotters know about the Jargon File anymore? (here or here or here.) It's sad how classic hacker history is so quickly forgotten.
http://www.catb.org/jargon/htm... : kludge
1. /kluhj/ n. Incorrect (though regrettably common) spelling of kluge (US). These two words have been confused in American usage since the early 1960s, and widely confounded in Great Britain since the end of World War II.
In English, the soft "g" is pronounced as if it has a "d" in front of it. Kluge rhymes with huge. Kludge, on the other hand, would rhyme with sludge or judge.
http://www.geoffreylandis.com
Why don't they simply add another record ("source") to help make the driver comparison? A typical Microsoft solution I would say.
Windows already keeps track of the source when ranking drivers, it's just MSFT changed the default Window policy to ignore it (to address certain issues, some technical, some political) and apparently used this kludge to mitigate some of the tradeoffs. The blog description skipped over several steps on how Windows ranks drivers. The first and main criteria is on how a driver is signed (i.e., the source), and only after that does it potentially need to tie-break based on the blog's description of hardware IDs, dates, and file versions.
Lowest rank score wins, and an inbox driver (i.e., a driver included with Windows) is scored 0x0D000003, which is higher than a WHQL signature score of 0x0D000002 or 0x0D000001 (according to setupapi.h in the Windows SDK). However, in Windows 7 the default policy was changed to now treat all signers the same, which now effectively ignores the source. Apparently this date is used to still try to favor vendor drivers despite this change in policy.
That's when we last touched them.
No kidding. I miss the old days of computing. These days, computing is no fun. Complex, unstable, buggy, etc. :(
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
I hate to say it, but really it should "just work".. given Microsoft *can* control what drivers are installed, I simply don't understand why hardware drivers aren't maintained through a quality controlled channel, let people choose which version they want, but otherwise have a default currently supported (and tested in at least the most common hardware configurations) driver that is delivered through windows updates or something...
One of the reason's I (as a Windows admin, and Linux admin too) enjoy using an Apple Mac is because I *never* have to dick around with drivers. This is likely also a major contributor to touted enterprise support cost savings at IBM despite higher initial buy cost for their Macbook Pro fleet.
I realise all the myriad configurations would make extensive testing of every configuration improbable, something that Apple has an advantage over by controlling the hardware as well as OS, but I also refuse to believe this is an insurmountable engineering problem.
Using 1899-12-30 vs 1899-12-31 is due to counting from 1 instead of 0, and screwing up 1900-02-29 in Lotus 1-2-3...
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
The driver release date should be embedded in the files, but apparently that isn't what is happening and they go by file timestamp. I'm fairly certain that executables/dlls can contain a release date.
That's not how it was back in the Amiga days.
You mean the days when simply plugging in some fast RAM caused half your software to stop working? 8)
Both my A1000 and A1200 were the most fun computers I ever owned, but man, Amiga programmers were the worst. They understood nothing about making software for a proper OS, especially when copy protection was involved (as it always was).
>It's a fucking cluster fuck out there on EVERY OS.
Yes, but where the cluster is and why it's there changes.
Linux packages are definitely a nightmare for developers, but solutions are being worked on, GUIX is able to provide transaction updates and multiple versions without conflict. Flat-pack and docker, allow distribution by third parties that are isolated from the underlying system.
They can't compare version numbers? This is Computer Sci 101. As bad as their stupid date idea. Instead of it being the correct yyyymmdd they wanted it mmddyyyy. Yea, that'll sort well. Dumbasses.