The title is a gross exaggeration of the policy change MS is making. Come 2021, what will go away is the ability to sign drivers for Windows 7 and 8 without passing WHQL/HLK compliance tests. That's it. You can still update compliant drivers, and you can still ship unsigned drivers if your users are willing to disable signing (not great, but there are plenty of shitty vendors who do this already).
Are there some number of important drivers that absolutely can't (rather than currently don't) pass WHQL/HLK tests? Sure, but I can't help but feel that the main "victims" of this will be shitty vendors with buggy drivers that have lagged in supporting newer Windows variants (and have thus kept their users stuck on older variants). Is OSR one of these shitty vendors? Maybe not, and they are a paragon of quality stuck in a rare corner case of WHQL/HLK compliance. But it does sound like they have spent the last year complaining about the policy change rather than working to meet WHQL/HLK compliance - I don't see any evidence in their post of working with MS to improve the WHQL/HLK tests.
If your customers aren't willing to install unsigned drivers (and none of mine are), then the new driver will have to be put through the HLK tests and submitted to Msft for signing.
My issue isn't so much the testing/signing process, but that I've had an HCK test suite setup for the past 4 years that has worked just fine. It will have to be replaced w/an HLK test setup, the release engineer and I will have to learn a new process, and possibly get a new signing cert. It's not a trivial process, but one we can work through.
> the main "victims" of this will be shitty vendors with buggy drivers that lagged in supporting newer Windows variants
Some of us have to support customers who are running old versions of Windows, and sometimes we just need to add new features.
Think about what you're saying. There's no reason to denigrate vendors. Also, it's not always about bug fixes. A lot of us really care about the quality of our drivers and our customer's experience. It helps everyone stay in business.
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.
What does WHQL/HLK involve and how does it work for independent developers and software-only drivers. I know that is generally not demographic of people writing windows drivers, but I'm curious as I have a half written driver that I plan to eventually finish, but the whole design is a bit odd.
I've run the HCK test suite (haven't tried the HLK, yet, bu from what I recall reading, the setup is similar). Basically, you need 2 servers, one to run HLK Studio and the Controller, and the other to run the HLK Client where the driver will be tested. Under HCK, the servers have a network connection.
You use the Studio/Controller UI to select and configure the tests and to find and select the driver on the remote server to be tested. Selecting tests is a bit odd on a software-only driver, but through trial-and-error and a lot of reading, I was able to find an appropriate set (it's a file system minifilter).
Once you start the tests, go find something else to do - the tests ran for about 12 hours in my case.
When you come back, you have to very carefully use the UI to collect the driver and the test results into a package file. You separately sign the package file with a cert that has been previously submitted to Msft (so they know who signed the package), then use the UI to upload the package to a Msft URL.
There's a website where you can view the signing process - it goes through several stages. In my case it took anywhere from 10 minutes to a few hours to get through all the stages. At the end, if all goes well, you'll be able to download a zip file that contains your driver signed by Msft. Once you have your driver, put it in an installer (we used WiX [0]) along with any other components (like a nice userspace tool for configuration, or to run as a service and load the driver to do useful things)
For a software only driver, it's a lot of busy work. I really don't think the HCK exercised my driver at all. Nevertheless, either me or the release engineer at work got through the process several times.
How do you permanently disable signing on 64-bit win7? Last I checked it wasn't possible to do cleanly, you end up needing user interaction for every boot, or you get a nag border.
> But it does sound like they have spent the last year complaining about the policy change rather than working to meet WHQL/HLK compliance
They seem to be a company doing many custom development and will have hundreds (thousands?) of separate projects. It seems reasonable they wouldn't try to pass HLK for everything just in case it needs work in the future.
Are there some number of important drivers that absolutely can't (rather than currently don't) pass WHQL/HLK tests? Sure, but I can't help but feel that the main "victims" of this will be shitty vendors with buggy drivers that have lagged in supporting newer Windows variants (and have thus kept their users stuck on older variants). Is OSR one of these shitty vendors? Maybe not, and they are a paragon of quality stuck in a rare corner case of WHQL/HLK compliance. But it does sound like they have spent the last year complaining about the policy change rather than working to meet WHQL/HLK compliance - I don't see any evidence in their post of working with MS to improve the WHQL/HLK tests.