Windows 11 24H2 goes from “unsupported” to “unbootable” on some older CPUs

[leadeater]

39 minutes ago, Kisai said:

Linux has no linear comparison with Windows. You can still run the 2.x kernels on current hardware if you're hard pressed to do so *cough*cough*redhat, 2.6.32 2024*cough*

Which version of Red Hat are you thinking of? RHEL 6 is 2.6, RHEL 7 3.10, RHEL 8 4.18 and RHEL 9 5.14. RHEL 7 essential OEL now btw.

 

But yea you can run pretty well fine on a super old kernel version, if you have to. Or if you have to patch in something you need in to an older kernel.

 

Spoiler

Every time I write Red Hat I type Red Hate lol

 

[Kisai]

14 minutes ago, leadeater said:

Which version of Red Hat are you thinking of? RHEL 6 is 2.6, RHEL 7 3.10, RHEL 8 4.18 and RHEL 9 5.14. RHEL 7 essential OEL now btw.

 

But yea you can run pretty well fine on a super old kernel version, if you have to. Or if you have to patch in something you need in to an older kernel.

 

Yeah, RHEL 4, 5 and 6 are all 2.6.x

Redhat 7 (from 2001) used 2.4 all the way to RHEL 3.

 

Redhat was infamously always big on staying on old kernels.

 

Then everyone got on the version inflation bandwagon.

https://thomaspark.co/2011/08/version-inflation/

 

At some point you just go "does the version number matter?", With Windows, and quite possibly only Windows, there is this wacky temper tantrum of unnecessary UI changes to included software (eg Notepad, Word Pad, Paint, Calculator, etc) , not just the OS User interface. With MacOS X? If you installed 10.4 originally, chances are every included software product since is still tied to your apple account, and still works on the current version, because Apple kinda seems to acknoledge the long tail problem that if you keep changing the UI people lose familiarity with it.

 

But under the hood, it has never mattered if Calculator and Notepad were running on Windows 95 or Windows 11.

 

[leadeater]

2 hours ago, Kisai said:

Then everyone got on the version inflation bandwagon.

 

lol Chrome, bigger = better 

[StDragon]

Whatever happened to just using the date and time in numerical format?  You'll never run out, and the number would be far more meaningful.

At least MS does it right with year and 1st / 2nd half of the year.

[Sauron]

On 2/13/2024 at 10:07 PM, DuckDodgers said:

It's unclear why POPCNT has become the load-bearing CPU instruction for a whole bunch of Windows components, but it looks like the Windows kernel, the system's USB and network drivers, and other core system files now require the instruction

I think it's unlikely this was intentional, someone probably accidentally changed whichever compiler option was telling it not to use that instruction and the rest is history.

[starsmine]

1 hour ago, Sauron said:

I think it's unlikely this was intentional, someone probably accidentally changed whichever compiler option was telling it not to use that instruction and the rest is history.

for kernel? I'm sure it was intentional., you generally don't accidently do things with a kernel three quarters of a year in advance when you can just recompile if this is your argument.

There is negative incentive to support core 2 for windows as all it does is lock you into slower algorithms for zero gain of install base. Like we are talking about supporting CPUS that came out before chrome did.

[Sauron]

9 minutes ago, starsmine said:

for kernel? I'm sure it was intentional., you generally don't accidently do things with a kernel three quarters of a year in advance when you can just recompile if this is your argument.

There is negative incentive to support core 2 for windows as all it does is lock you into slower algorithms for zero gain of install base. Like we are talking about supporting CPUS that came out before chrome did.

I agree they wouldn't care, I just don't understand why they'd intentionally and suddenly start using this instruction they didn't use to before. I guess it's possible they had a "core 2 support" flag in their pipeline that they intentionally removed and it caused the compiler to sprinkle the instruction around, but I doubt they went out of their way to use this specific instruction more.

[Kisai]

52 minutes ago, Sauron said:

I agree they wouldn't care, I just don't understand why they'd intentionally and suddenly start using this instruction they didn't use to before. I guess it's possible they had a "core 2 support" flag in their pipeline that they intentionally removed and it caused the compiler to sprinkle the instruction around, but I doubt they went out of their way to use this specific instruction more.

It's more likely that code was removed or "optimized out" to shave boot time or something, or maybe close a potential security hole by leaving fallback code in.

 

Like a few days ago there was a whole bunch of patches to VMWare going back to out-of-support versions and the "work around" was to remove USB support from VM. You know a problem is bad when you have to fundamentally change how something "always worked". As it is, VMWare and even VirtualBox is increasingly useless to run "old" software in without having to go back to old versions of VMWare and VirtualBox (6.0.24 is the last usable version that can run Windows XP games) where security exploits exist because the OS or software you need is dependent upon those still being possible.

 

 

[leadeater]

2 hours ago, Sauron said:

I agree they wouldn't care, I just don't understand why they'd intentionally and suddenly start using this instruction they didn't use to before. I guess it's possible they had a "core 2 support" flag in their pipeline that they intentionally removed and it caused the compiler to sprinkle the instruction around, but I doubt they went out of their way to use this specific instruction more.

They won't be using it "more", they will be removing support for the the alternative for not supporting it. It is very unlikely Microsoft was setting any compiler flags to not use this before and it's even less likely a compiler would not use this instruction, my prior post.

 

The issue is both performance related and bug/support related. If entirely different code paths are being taken then you have completely different paths and failure modes for issues and unlike popular belief Microsoft do actually do inhouse kernel stability checking across a wide range of hardware and lots of it and they'll certainly have statistical data that shows hardware that does not have this instruction has higher rate of of errors. Combine that with actually no need to support such old hardware for Windows 11 and you have perfectly reasonable outcome, ~0.0001% of Windows 11 or potential Windows 11 users affected.

[leadeater]

On 3/5/2024 at 7:50 AM, E-waste said:

Sure, but you can use the oldest of the oldest x86_64 bit CPUs from AMD on all Linux systems, but dropping support for hardware this aggresively should be a criminal act against the environment.  We aren't there yet, so Microsoft can pull this horseshit and flood the planet with electronic waste.  They are almost as bad as Apple now, basically right there with them.  We now have two "apple" companies that vant you to throw your computer in a dump (and your phone too) every six years, all for PROFIT, not because they care about our planet, or humanity, or the people working as slaves in Africa.

 

It's gotten so bad that there is more slave labor today than there ever was 400 years ago.

What is the point of running an operating system that cannot run basically most modern software, if your argument is it still works today.

 

You have a good point about supporting legacy systems and legacy software and that is a step better than just running old unsupported Windows but we all know 1000% that is actually what happens, a lot in manufacturing.

 

It's like arguing Parallel ports on computers can still be used and are functional, yes they are but good luck getting a new printer to work properly with a Parallel port. Some things shouldn't be done.

[Sauron]

29 minutes ago, leadeater said:

They won't be using it "more", they will be removing support for the the alternative for not supporting it. It is very unlikely Microsoft was setting any compiler flags to not use this before and it's even less likely a compiler would not use this instruction, my prior post.

 

The issue is both performance related and bug/support related. If entirely different code paths are being taken then you have completely different paths and failure modes for issues and unlike popular belief Microsoft do actually do inhouse kernel stability checking across a wide range of hardware and lots of it and they'll certainly have statistical data that shows hardware that does not have this instruction has higher rate of of errors. Combine that with actually no need to support such old hardware for Windows 11 and you have perfectly reasonable outcome, ~0.0001% of Windows 11 or potential Windows 11 users affected.

I guess in that case the question becomes "why did it ever work in the first place?", considering C2Ds were never officially supported

[leadeater]

2 minutes ago, Sauron said:

I guess in that case the question becomes "why did it ever work in the first place?", considering C2Ds were never officially supported

Because they still set the allowed hardware target to be as low as C2D, you take one path if you have the instruction and another if you don't. That's how all software works, not everyone has AVX-512 or even AVX2 but software can use that when it's there and not when it isn't.

[Sauron]

Just now, leadeater said:

Because they still set the allowed hardware target to be as low as C2D, you take one path if you have the instruction and another if you don't. That's how all software works, not everyone has AVX-512 or even AVX2 but software can use that when it's there and not when it isn't.

I know, I'm wondering why they left that path in despite no official support, only to remove it later.

[leadeater]

Just now, Sauron said:

I know, I'm wondering why they left that path in despite no official support, only to remove it later.

Probably along the same lines for why a lot of things are or are not done, if it isn't broke then don't fix it. "Minor" differences or changes go a very different analytical consideration path when you are considering affecting many tens of millions if it's not so "minor" and it does cause problems.

 

But also unless there actually is a benefit at all then why do it at all?

 

Which then leads on to the actual situation, Microsoft latest Insider Preview is using the new Rust Kernel which is the root cause for this. Not because Rust doesn't support older CPUs like those but if you are making such a huge change you want to do a lot of things and one of those is reduce the required testing and the potential for issues which means cutting out support for unreasonable hardware.

 

If it were just a compile setting change and some code modifications then the reasoning would have to be a lot more specific, but here you have to argue why to support rather than why it was removed.

 

Windows 11 24H2 is the introduction of the Rust Kernel, so you must justify what hardware is to be supported and if you can't then it's not.