Separate directories for system and vendor drivers. System directory given lowest priority.
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.
Drivers have a priority field 0-255. Vendor drivers can only use 128-255. System drivers start at 255 baseline. Highest priority (0 is highest) always wins, and ties are broken with version or date comparison or what-have-you.
Right, the system baseline (255) starts well below the vendor's max priority (128). The vendor would start at 254 presumably, and overeager vendors wanting to start at 128 would only harm themselves (in terms of future flexibility).
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.
Actually, I think you made that too easy. Microsoft itself has lots of legacy drivers - probably thousands. Changing them would require finding, recompiling, retesting, and redistributing all of them at best. That's certain to be expensive, and may not even be possible in all cases, so you're probably not going to do it.
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.
Not the grandparent, but my first thought would be to use the signature. If the driver's signed by Microsoft, and another matching driver is signed by the hardware vendor (or is unsigned and the user has already gone through the relevant approval tomfoolery), then prefer the vendor's.
> So how would you fix this, keeping in mind you are not allowed to touch the vendor driver's binaries in any way?
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.
This is far from a field with which I have experience, so I can't provide any sort of solid answer. I imagine that it would be a significant change, and would take time to do right.
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.
You add a metadata to the MS drivers that tells Windows they have a special low priority. If a driver doesn't have the flag explicitly set, then it gets a default "normal." priority.
Fix the license agreement with the vendor. If I'm going to be nice enough to distribute your driver for you, I reserve the right to alter its metadata in any way I deem necessary.
