Why are all Windows drivers dated June 21, 2006?
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
According to the text, it's designed to prevent the problem you describe:
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.
I don't know where this is going wrong for you but both the file version and the timestamp are things you can manipulate on that driver file. Might help, although you're in trouble if the manufacturer's driver isn't a perfect match to the hardware ID.
The text shows that the driver is working as intended. The newer driver is being chosen automatically. The problem is that the newer driver is the Microsoft one. The sad thing is that I don't even know the Manufacturer of the driver anymore. It was painted on the controller and has since rubbed off and the driver file itself just shows up as "Generic Joystick Driver" or something like that. At one point, it got identified as an XBOX 360 controller. :(
1) Have you tried Googling the hardware ID
2) Take a photo and do a Google reverse image search
Does this really work most of the time? I'm typically only doing this to find the source(or more information) about an image I've found online.
If not, you might be able to do some hex editing if you can find the location for the date, and bump it to newer than the windows date.
I dunno, I remember getting my first proper joystick (to play Descent Freespace) maybe 16 years ago and it came with both serial and USB connectors..
Nothing profound about this kludge IMHO.
Fix your driver negotiation mechanism. This is like a "Hm, well, I do like weekends and it's 4pm on a Friday..." solution.
That's not a feature, that's an existential risk to MS as a company.
Just not in a positive way.
Disclaimer: near zero forethought
When MS needs to supersede the vendor driver, they can issue priority 253 (i.e. vendor + 1) graciously or 127 violently. They can also retract the 127 driver or overwrite its priority back to 255 when appropriate.
I'd change the premise, since Microsoft definitely is allowed to enforce policy on vendor drivers through its WHQL/code signing program, and has wielded this power.
Not that I necessarily agree that all drivers should have to be signed, but refusing to sign drivers to solve quality problems is entirely in scope for having such a code signing program in the first place. Unsigned drivers Microsoft can simply wash their hands of: "We can't enforce policy on those, sorry." Since manufacturers want signed drivers to ease confusion, they will come in line, especially since it's a particularly low bar to set.
But not a decade. Surely, something could have been introduced in any of the 3 OSs released since that date that could have addressed the issue.
I'm not trying to play them out to be evil, or incompetent. I think this is just an example of a problem that was on the "let's do this tomorrow" list for 10 years running. Understandable, in a way, but somewhat less understandable when in the context of a giant like MicroSoft.
So how would you fix this without changing any drivers from any vendor that have already been released?
Also keep in mind that this is a minor convenience feature that most people will rarely see, so you probably don't have a massive budget.
Wouldn't require modifying vendor drivers or legacy installation or whatever. Just move the system drivers.
I must be missing something pretty fundamental here, because this seems like the immediate natural solution.
----
Disclaimer: I've had basically no meaningful-to-me interactions with drivers that weren't mediated by an installer or package manager, and I haven't used any form of Windows in 10 years.
So check the manufacturer of the driver, and if it's Microsoft then assign the lowest priority.
Am I missing something here?
The drivers provided with the OS are generic. The drivers you can download are bespoke and offer additional features.
A perfect example is Microsoft's webcams. The built in driver will run the webcam fine. The downloaded driver adds "fun" overlays, filters, and software to control it.
So that's why not. Users won't want their webcam driver being downgraded every time a Windows Update is installed in the background. Even for Microsoft hardware.
It does seem to me that, at least somewhere along the line, we'd probably prefer the generic Windows driver from 2017 over the specific vendor driver from late 2006, though...
The adage "If it's stupid but it works, it isn't stupid" may apply here... or this may be the perfect counterexample.
EDIT: It's also possible that this is the "simpler" solution. The behavior of the driver selector probably went through a litany of testing before this problem was discovered. Changing the driver ranking algorithm is a major modification that would warrant another litany of testing. Given budgets and deadlines, I can see someone implementing this hack as a clever way to avoid re-testing a major component.
Technical debt is common for the same reasons monetary debt is common.
Basically people lacking the knowledge or proper capabilities in managing the whatever they are supposed to manage? ;)
If it's stupid but it works, it's still stupid and you just got lucky.
They also produce custom drives for that hardware (e.g. webcams). If they follow your plan then both the OS driver and the custom driver have the same priority and newer versions of the OS may disable Microsoft's bespoke hardware drivers.
He's not promoting anything, he's just writing about a tidbit people would be interested in.
If you don't believe me, go through his blog archives. You'll most likely learn a thing or a dozen.
Previous beta releases only had a very limited set of drivers.
Microsoft greatly remodeled the driver model in Vista so that's why drivers can't be older than this date.
[1] https://en.wikipedia.org/wiki/User-Mode_Driver_Framework
I sort of get WHY they don't priorities highest file version above timestamp, but it also seems to indicate that they have an issue with managing drivers. I'm sure it's more complicated than I imaging, but shouldn't there by a way to tell Windows that you installed a driver and you want to use that one and not the bundled/updated driver from Microsoft... Well I suppose there is, give it a newer timestamp.
Linux has their drivers in the kernel tree for the most part, with no promise of backwards compatibility whatsoever. macOS is fine overall, but I've never had a major update not trash major parts of the OS, whether that's the build environment, some subset of GUI apps, or general hardware support.
Windows has a driver model. While not a promise, third parties can typically expect drivers to keep on working. I've never experienced an OS other than Windows with such broad hardware compatibility and such broad binary compatibility. Except in rare instances, just about every piece of non-driver software from the Windows 95 era works unmodified on modern 64-bit Windows. AMD64 did not exist when Windows 95 was released. Drivers also typically work unmodified, the major exception being a pretty significant change around the time of Windows Vista.
Yep, see Linus Torvalds's rant about this: https://www.youtube.com/watch?v=1Mg5_gxNXTo&t=6m37s (skip to 6:37 and keep watching).
What needs to be fixed in this driver selection scheme by the way?
That way we thought we could tell which version the user was using over the phone by asking them to do a DIR (useful if they couldn't start the application to see the version number in there).
Of course, this system rapidly broke down because users would copy the files across to different floppies or hard drives, causing the file dates to be reset to whatever it was at the time!
"I have a USB 3.0 controller in my system where Microsoft took over control of the driver, probably due to the hardware manufacturer going under. Anyway, the driver Microsoft provide is signed by the same certificate as they use to sign other drivers for Windows. But in this case, you would want the Microsoft provided driver to win out over any manufacturer provided driver because they are all broken in some way."
Of course they could have separate signing certificates for 'overriding' drivers, but that would be just as much a hack as using the time stamp.
It's your system, and if you chose to install the vendor driver (even if it's broken/old), it should use it... no?
- a user installed a top of the bill vendor driver.
- vendor goes out of business.
- driver has enormous security issues/doesn't work with some newer hardware.
- Microsoft releases an improved driver.
Should Windows:
- assume the user knows better and keep using the vendor driver?
- ask the user whether it can remove the outdated vendor driver (and any older one(s) still present), so that the Microsoft-provided one can take over? (even if the vendor-provided driver targets a broader range of USB devices?)
- do what it does now?
I think the number of people who would rightfully want to still pick the vendor drivers can easily be counted on the fingers of one hand, so my $0.02 is on the last.
All others would be baffled by any question asked and accidentally might pick the wrong answer.
It'd be far less of a hack, IMO. At least that particular hack wouldn't be totally subverting something with as much predefined semantic meaning as a timestamp.
Besides, it could actually fit into Microsoft's organizational structure reasonably well. The team that maintains default drivers could have one signing key, and the team that maintains override drivers could have a different signing key. Same deal for Microsoft teams/departments that develop/maintain drivers for Microsoft hardware projects (like Microsoft-branded HIDs).
So according to MSoft developers, a property being unused and redundant = a profound purpose?
Why not just remove the date criteria completely if you want to ignore it rather than trying to work around it by mutating the data?
> Are you just a bunch of slackers?
since the first answer that comes to mind is "Yes, it would seem so".