7 ms·

Windows 11 was the time to do so, and they missed it. I'd bet it was assessed, briefly, as too big a change to be acceptable if old devices were not going to be

Windows 11 was the time to do so, and they missed it. I'd bet it was assessed, briefly, as too big a change to be acceptable if old devices were not going to be compatible.

deleted 27d ago
[deleted]
pjmlp 27d ago
That would be yet another reason to complain about Windows 11 though, unfortunately.
RandomGerm4n 27d ago
The solution would be simply to add a warning as a temporary measure preferably in red text and in a way that would scare the average user. This warning should be accompanied by a call to action urging users to contact the device manufacturer and ask them to release a new driver. Then companies would have no choice but to either create a new driver that runs in user space or be constantly inundated with support requests from customers.
- pjmlp 26d ago
  Unfortunately that doesn't work, when a warning sits between a user and the application they want to run, they will always say yes, and then someone has to clean all those browser toolbars.
0cf8612b2e1e 26d ago
Win 11 already invalidated quite a few relatively modern systems. As far as I know, it was an arbitrary threshold which has not materialized into an actual hardware requirement to run. As a joke, someone installed Win11 on a computer with a Pentium 4.
- not_a9 26d ago
  Technically the hardware threshold is sort of real for making virtualization based security usable and useful.
  - pjmlp 26d ago
    Exactly, it was the whole set of virtualisation based security that is optional in Windows 10, and was made compulsory on Windows 11.
not_a9 26d ago
Microsoft did break backwards compatibility with some drivers (packed stuff that relied on being able to write to executable sections, for instance) w/ HVCI and then with some other stuff (for instance, drivers using push+ret for obfuscating function calls + some exception handling related machinery some virtualization based obfuscators used) with KCET. With that being said virtualization based security is not mandatory, though compliance is needed for signing new drivers (note: this is funky too and some drivers will do HVCI-noncompliant things when it’s disabled, like some anticheat drivers hooking #PF to more efficiently catch unsigned code execution in HVCI-free scenario). I think next backwards compatibility breaking move will be enabling SMAP.

Windows 11 was the time to do so, and they missed it. I'd bet it was assessed, briefly, as too big a change to be acceptable if old devices were not going to be compatible.

deleted 27d ago

[deleted]

pjmlp 27d ago

That would be yet another reason to complain about Windows 11 though, unfortunately.

RandomGerm4n 27d ago

The solution would be simply to add a warning as a temporary measure preferably in red text and in a way that would scare the average user. This warning should be accompanied by a call to action urging users to contact the device manufacturer and ask them to release a new driver. Then companies would have no choice but to either create a new driver that runs in user space or be constantly inundated with support requests from customers.

pjmlp 26d ago
Unfortunately that doesn't work, when a warning sits between a user and the application they want to run, they will always say yes, and then someone has to clean all those browser toolbars.

0cf8612b2e1e 26d ago

Win 11 already invalidated quite a few relatively modern systems. As far as I know, it was an arbitrary threshold which has not materialized into an actual hardware requirement to run. As a joke, someone installed Win11 on a computer with a Pentium 4.

not_a9 26d ago
Technically the hardware threshold is sort of real for making virtualization based security usable and useful.
- pjmlp 26d ago
  Exactly, it was the whole set of virtualisation based security that is optional in Windows 10, and was made compulsory on Windows 11.

not_a9 26d ago

Microsoft did break backwards compatibility with some drivers (packed stuff that relied on being able to write to executable sections, for instance) w/ HVCI and then with some other stuff (for instance, drivers using push+ret for obfuscating function calls + some exception handling related machinery some virtualization based obfuscators used) with KCET. With that being said virtualization based security is not mandatory, though compliance is needed for signing new drivers (note: this is funky too and some drivers will do HVCI-noncompliant things when it’s disabled, like some anticheat drivers hooking #PF to more efficiently catch unsigned code execution in HVCI-free scenario). I think next backwards compatibility breaking move will be enabling SMAP.