More on NX Insanity(os2museum.com)
os2museum.com
More on NX Insanity
http://www.os2museum.com/wp/more-on-nx-insanity/
10 comments
And the counterpoint: sometimes you do get to look at the secret sauce and find out that decision you thought was carefully considered is actually just a poorly engineered workaround annotated with the equivalent of a shoulder shrug and "we needed to ship and nobody has complained loudly enough for us to revisit it".
Here's a related story on why Microsoft might not want to believe the result of a query of hardware capabilities:
https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...
>In other words, whenever DirectX asked, “Can you do this?” they answered, “Sure, we do that,” without even checking what the question was.
https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40...
>In other words, whenever DirectX asked, “Can you do this?” they answered, “Sure, we do that,” without even checking what the question was.
That's a good quote; but I think that the crucial sentence is this one:
> The driver must have been written by the sales department.
> The driver must have been written by the sales department.
Force enabling a feature that the CPU says doesn't exist seems like rather the opposite of that principle.
> That’s right. If SSE2 is reported, KiTryForceEnableNx does nothing. How does that make sense? I don’t know. It is true that all AMD processors which have SSE2 also have NX (and it can’t be disabled). But all Intel Pentium 4 CPUs made before late 2004 (and some made after) have SSE2 yet no NX.
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[0].
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[1]. Both blew nasal demons.
[0] Section 3.1 https://docs.microsoft.com/en-us/previous-versions/windows/i...
[1] 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 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[0].
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[1]. Both blew nasal demons.
[0] Section 3.1 https://docs.microsoft.com/en-us/previous-versions/windows/i...
[1] 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.
> But it’s causing trouble because if NX cannot be enabled on an Intel CPU for whatever reason (such as running in a VM on a host with disabled NX, thanks Intel!), Windows 10 doesn’t believe the CPUID information and tries to enable NX anyway, which blows up.
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.
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.
It seems like it shouldn’t be too difficult to just test if it works, if the processor says it does.
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.