A VMM on an NX-capable CPU that doesn't support NX doesn't seem like something that's worth MS supporting. I'm going to guess they talked about it internally, and decided that whatever they needed to fix was worth the tradeoff. Maybe there's one CPU where NX is in fact supported but for whatever reason it's missing in CPUID, and you've never seen that CPU. Also, honestly, a VMM that doesn't support NX sounds remarkably like malware, if you run into it in production and not on the system of a hobbyist writing their own VMM, and failing hard when you know the CPU you're on supports NX and you know that CPUID is lying to you is an entirely reasonable decision.
Similarly, re skipping force-enable on 32-bit SSE2 CPUs - there's probably one CPU where the force-enable codepath causes some subtle problems, and this is the fastest/easiest way to identify that CPU, and they're not terribly concerned about accidentally missing some other cases. And again, you neither have the comments nor the `git blame` (or whatever MS uses) of that code nor the internal trouble ticket where someone spent weeks chasing down an elusive CPU bug. Of course it makes no sense to you.
And if there is some real problem behind these two cases, it's hardly true that "the original issue is long gone" - Windows has very long support cycles. This isn't a "problem in the IT industry," it's the reality of the game. If you want your code to work on real-world machines and you want real-world customers to pay your real-world salary, you have to write code for the world as it actually is, not as you wish it would be.
(I didn't know that, maybe it helps someone else)
>In other words, whenever DirectX asked, “Can you do this?” they answered, “Sure, we do that,” without even checking what the question was.
> The driver must have been written by the sales department.
This is an odd choice, and from the sound of it -- they're only checking SSE2, assuming its presence means that NX can be enabled, enabling it and ... nasal demons of some kind.
I'm guessing someone didn't read the specs carefully enough on the Intel processor side, but at the end of the day it ended up being a "Won't Fix" simply because they explicitly list both SSE2 and NX as required.
It's not great to fail with what I assume is some error message that doesn't simply say "Your processor is not supported, see our 6-page requirements document online on another computer". It'd be ideal if the OS could accurately check its minimums.
I think of the application's I've built (nothing deployed widely), it's rare that I've had to do operating environment validation (the need for it in the applications I write is minimal beyond "can I allocate a little memory"), and from some brief reading, it sounds like there's a more than a few edge cases involved.
If my experience as a user (who buys AMD products, usually) is any indication ... No Man's Sky and a 3D program who's name escapes me both required SSSE3. Both blew nasal demons.
 Section 3.1 https://docs.microsoft.com/en-us/previous-versions/windows/i...
 I seem to recall it was something like SSSE4.2 or some oddness, but I couldn't find a reference to it ... only SSSE3, which had the same problem of having an extra "S", confounding Google.
edit: and grammar and speling.
This seems like a "Doctor, it hurts when I do this." kind of thing. Just don't do that.
Is there any good reason to disable NX systemwide on a VM host? Seems kinda risky.