5 ms·

> You can still update compliant drivers If your customers aren't willing to install unsigned drivers (and none of mine are), then the new driver will have to

> You can still update compliant drivers 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.

cpgxiii 6y ago
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.
- TillE 6y ago
  > almost everyone 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.
  - cpgxiii 6y ago
    > 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.
- PeterGV 6y ago
  Passing the WLKs is, absolutely, a best practice. 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.
  - viewer5 6y ago
    > 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.
    - PeterGV 6y ago
      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.

cpgxiii 6y ago

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.

TillE 6y ago
> almost everyone 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.
- cpgxiii 6y ago
  > 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.
PeterGV 6y ago
Passing the WLKs is, absolutely, a best practice. 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.
- viewer5 6y ago
  > 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.
  - PeterGV 6y ago
    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.