I will absolutely denigrate vendors who lag behind on driver quality and support, particularly vendors who sell expensive equipment tied to ancient and shitty drivers who can't be bothered to update them support new Windows versions.
Outside of a small set of drivers that WHQL/HLK testing may not work for, an unsigned driver means (1) the vendor doesn't care (i.e. "sold you expensive equipment and have you by the balls") and/or (2) the driver is a horrible buggy stability and security nightmare.
> A lot of us really care about the quality of our drivers and our customer's experience.
And for almost everyone, that means WHQL compliance.
A 95% solution which completely fails to account for the remaining 5% is an enormous problem. As the article explains, HLK testing isn't really designed for non-hardware drivers and the solutions are strange at best.
You're not actually improving quality in this case, you're just making us do convoluted busywork.
> As the article explains, HLK testing isn't really designed for non-hardware drivers and the solutions are strange at best. You're not actually improving quality in this case, you're just making us do convoluted busywork.
There's a lot common to driver development that's separate from purely interacting with hardware (memory management, filesystem interaction, security, etc), some of which the HLK covers. Plenty of non-hardware drivers are capable of bringing down the system or breaking things if they do something bad in kernel mode.
To be clear, the article is complaining about their specific case in which they claim to have a driver that explicitly violates nominal filesystem invariants and "cannot" pass HLK testing, not that HLK compliance is inherently a bad fit. Whether or not a different set of tests or a negotiated "Contingency" test filter are possible is a different question.
But, with all due respect, Mr. cpgxiii, you seem to not understand the vast extent of systems that use Windows.
It is simply NOT POSSIBLE to run the HLKs on certain hardware systems. Let me give you a few examples:
We write a driver for an unmanned aircraft. The driver runs on a custom processor box, with custom, on-board hardware, that's inside the aircraft. This custom system will not support the HLK client. Ever. The hardware for which we've written the driver cannot be separated from the custom system. This customer is now screwed.
We write a driver for a device that lives in a piece of industrial equipment. Even if we could pull the boards for which the driver was written, and stick them into a system that was capable of serving as an HLK client, the hardware is designed in such as a way that is designed to be never powered off. This device, therefore, does not support ANY non D0 power states. While it might be possible to get his device to pass the HLKs with a LOT of work, it's unlikely.
There are a lot of drivers/devices in the world that fall into similar categories to those above.
And, there is the case of File System Isolation Minifilters. Any such driver will never pass all 80,000 WLK tests (that's a real number, by the way) due to the way these tests are written. We have worked with MSFT for YEARS to try to get the Minifilter tests to treat Isolation Minifilters specially. MSFT simply does not have sufficient motivation to make this happen.
So, yeah, easy to say "just pass the HLKs" -- I wish it were that easy.
> the hardware is designed in such as a way that is designed to be never powered off
What kind of equipment is like this? Or is it common for factory equipment or something? And what would be the consequence of a total power outage (including generators failing, I guess)?
This isn't something I've heard of before, it's interesting.
After power-down, the system reboots, and the process needs to restart. All in-progress activity is lost. There's no suspend; There's no hibernate. There's no "modern standby."
There's "The system was powered off, soooo... we're going to let the glass furnace cool down, and in a few hours when it's sufficiently cool and everything else in the plant is ready, we're going to start up the process again."
Needless to say, this isn't the sort of behavior that'll pass the HLKs.
Outside of a small set of drivers that WHQL/HLK testing may not work for, an unsigned driver means (1) the vendor doesn't care (i.e. "sold you expensive equipment and have you by the balls") and/or (2) the driver is a horrible buggy stability and security nightmare.
> A lot of us really care about the quality of our drivers and our customer's experience.
And for almost everyone, that means WHQL compliance.