I find it hard to believe dropping legacy boot support saves hundreds of megabytes of any data in the OS, let alone source code. (If anything, the UEFI code is orders of magnitude larger / closer to that size, than legacy boot support.)
I could believe that dropping legacy boot support drops a lot of complexity and arcane, old code that's no longer as well-understood. However the actual footprint of that code can't be large. The boot sector is only 512 bytes, then you chain to a secondary and maybe tertiary step in the boot but those are measured in kilobytes or megabytes, hardly hundreds of megabytes (compiled).
But the fact is once the boot process has completed there's no longer any reason to refer back to any of the stuff that happened during the legacy boot while the operating system is running normally; by that point how the boot was accomplished is a non-issue. So it's not like, for example, supporting outdated/obscure hardware where you have to keep a bunch of drivers around.
> But the fact is once the boot process has completed there's no longer any reason to refer back
The instruction pointer is hardly the only state here. Doesn't the __SM__ structure (and the mess that came before) cascade into a bunch of configuration? It seems to me that it really could look like keeping a bunch of drivers around.
I realize that sounds a bit like a Monty Python critique of the Romans, but there’s no way I would/could use the platform as a daily workstation professionally. It served its last days as a home servant droid well, but just. It’s longevity in a low-demand role was only possible by augmenting it with an array of SATA SSDs and a hypervisor. I finally put it down a while back (and still had one backup mobo NIB for it). All the above relatively lightweight functions it was performing can be done with better performance on a far smaller footprint for size/power consumption/noise today. Those attributes are part of an improving performance profile. People talk about a performance plateau, which I’ve pushed back on in other posts as really being a demand plateau for many of its advocates. Case in point, using the phenom platform as a daily workstation. If one can even think about pulling that off, it can only be because their expectations have dropped very low for performance or their needs haven’t changed since Phenom was in its prime. Yeah it runs the old workloads like it always did (and why would it not? Even better when augmented with more modern hw/sw), but no way under the sun would I be able to overlay my current demand profile on a phenom platform and have anything but swamped resources and interminable delays. I say this as someone who fully appreciates the awesome power we have in a 5v/2A RPi smaller than a deck of cards, and what can be done a larger platform drawing less than 60w today, let alone what can be done with 1000w. The phenom platform is highly inefficient in comparison to the tools now at your disposal.
Maybe a keychain ornament.
Windows 10 will be widely used in 2031. You're not going to drop support for it and old CPU regardless of Windows 11 existence.
Would that really look so bad? Even the Linux kernel dropped 80386 eventually.
Windows 10 feature updates occasionally phasing out hardware support after a few years wouldn't seem wrong at all in my eyes, they could easily explain it as a trade-off necessary for getting "10 forever". And Windows users were already used to not getting their feature update immediately on older hardware, an eventual escalation from late to never wouldn't have been surprising at all.
The boundaries you ask for have already been in place, long before 11.
> providing trusted computing that might actually work this time.
Ahah, sure. <Pinky & the Brain tune starts>
One follow-on question - any insights into how what you wrote above explains why Microsoft dropped support for AMD Zen in Win11 (Zen+ and higher are only supported)? Looking at Wikichip, it doesn't seem like there's a feature missing, so perhaps there's an unfixable bug in Zen?
Only SSE4.2. It supports Intel CPUs without AVX2 since that was missing from some Celeron/Pentiums.
So Microsoft is going all in with hardware based security while everyone is still recovering from Spectre and Meltdown and dropping in additional layers of software fix CPU security flaws? Is there a betting pool somewhere on how long that will take to backfire?
That is really the difference between Win 10 and Win 11: Requirement for UEFI, TPM 2.0 and a CPU that does AVX2 and FMA3, and some kind of hardware-assisted virtualization.
UEFI allows them to rewrite their entire bootup codebase with only one target. Literally hundreds of megabytes of sourcecode will be removed from their tree, some of it dating back to the 80's, and replaced with something that is much, much smaller and cleaner.
TPM 2.0 and hardware-assisted virtualization allow them to move the kernel one level up in the privilege hierarchy, while properly verifying it during boot to eliminate entire categories of exploits and providing trusted computing that might actually work this time. (Not entirely positive, but it's a desirable feature for them.)
And having all the cpus that can support the OS also support the good vector instructions greatly raises the baseline against which most software is compiled. This is an often underlooked point: The benchmarks and the most performance sensitive programs might get multiple code paths or versions for different cpus, but by far the most software made for Win 10 still only targets a very low baseline. Even if it's not 32-bit, most programs only target the ancient SSE2 (!) because that's the baseline that's quaranteed to exist if you have a 64-bit cpu, never mind it's over 20 years old now.