I don't believe it.

You mean to tell me that Microsoft is doing a bad job with thier OS???

Preposterous. These 100 or so processes that its running to track my every breath are incredibly important to make sure im given the best ad experience.

It’s mainly due to PA Semi acquisition. These guys were the ones responsible of making excellent PowerPC processors, which were similar to what ARM has now.

These guys are probably happier now that they have more resources, target devices and tightly coupled software.

Yeah. Linux is also optimized to run well. Has a capable community and a few good design choices. Many people use it to run it on servers so I wouldn't be surprised if it performed well well on servers.

Also there is a well known fork that is used on millions/billions(?) of ARM phones. So it'd better be a good choice for that use case.

Microsoft absolutely could have made something comparable to Rosetta 2 for userspace if they were competent.

Rosetta 2 isn't an emulator, but a binary recompiler. It takes amd64 instructions, decodes them, and generates equivalent aarch64 instructions. The aarch64 instructions are then executed directly by the processor, performing the same tasks that the original binary would do on an Intel processor.

It's extremely difficult to do properly, but it's nothing inherently special to MacOS or Apple's ARM chips. ARMv8 has an attribute to enable strongly-ordered memory accesses, and it also supports native 4 KiB page sizes. Beyond those two solved concerns, there isn't any actual hardware barrier preventing binary translation. Individual amd64 instructions can be translated into one or more equivalent aarach64 instructions, and complex instructions or those using large registers like those in AVX-512 can be shimmed and implemented in software. An offset table can be used to deal with indirect jumps, and direct jumps can just be rewritten in the generated code. And as Apple has proven, it's even possible to support JIT-compiled code by intercepting jumps into executable pages and recompiling them before executing.

It's expensive in terms of time and engineering skills, but Microsoft had more than enough control over their own proprietary kernel to build something similar into Windows back when they first released it for ARM.

Apple hit a sweet spot with this. x86_64 applications run at acceptable speed (making the transition easy for people who buy the hardware) while not being SO good that there's zero reason for developers to start porting their software.

Small correction: the flag setting modes aren't undocumented. They're standardized extensions. ARMv8.4 added FEAT_FlagM, and ARMv8.5 added FEAT_FlagM2.

https://developer.arm.com/downloads/-/exploration-tools/feature-names-for-a-profile

IIRC, the only nonstandard ARM extension used by Rosetta 2 in Apple's processors is TSO, and that's also implemented by other manufacturers. It's also not a hard requirement to run amd64 under ARM. You can emulate it very slowly or restrict the application to a single core.

Apologies for the tangent, but I needed to make sure nobody could defend Microsoft's prior failings by saying "but Apple has secret hardware sauce".

Windows 10 and 11 both have ARM versions. 11's ARM version has had some major updates recently.

I dunno, overall Rosetta 2 seems to be incredibly successful. It seems like most people were able to transition without worrying too much about whether their software would work at all or not, which I think is undoubtedly the smoothest an architecture transition like this has ever been.

I know the cool thing is to hate on Apple for being Apple, but they have actually done a solid job with their transitions between instruction set architectures.

Ultimately, software developers and end users are forced to use the newer architecture, yes. But credit where credit is due, Apple chose to take the path of providing both hardware and software level facilities to make the transitions as seamless as possible over years-long timespans. They could have simply refused to support older architectures to force a migration down our throats, and indoctrinated fanboys would have opened their wallets anyway.

What they actually did was create compatibility layers, a multi-architecture executable file format, and binary translation frameworks built into the operating system. I fucking despise them for creating a walled-garden ecosystem and cult around their products, but I genuinely have to respect them for Rosetta and Rosetta 2. Developing a binary translation layer is a whole different beast than high-level emulation, and it's significantly more difficult to pull off correctly. The fact that they managed to do it twice, and do it damn-near seamlessly is impressive. Rosetta 2 even supports translating just-in-time compiled code, which is a huge pain point for that kind of thing.

If you follow the history of the Mac, it went through a number of major architecture transitions from 680x0 -> PowerPC -> Intel -> ARM. Each time, Apple supplied a decent emulator to support applications during the transition.

From a developer perspective, these were huge upheavals that came with a lot of drama but also offered some opportunities. The latter came from the fact that the bar was in some way set higher on the new platform and you could count on any code you compiled for it supporting certain base features. Every PowerPC, for example, had hardware floating-point. Before that, some CPUs did, some didn't. The Intel transition happened at the time when dual core had become standard and SIMD had become serviceable (with SSE2). The ARM transition has set the bar at 64-bit architecture for every CPU (since Apple had earlier dumped 32-bit on the iPhone side).

Windows/Intel has developed in a more evolutionary than revolutionary manner, which is easy to see if you look, for example, at all the legacy cruft in the Intel ISA. It's a sad sight. Supporting all that makes instruction decoding a nightmare. In theory, Intel/AMD could reinvent a new sleeker ISA if they could get Microsoft to commit to supplying a performant emulator for the old one? But I'm not holding my breath.

NT is not the majority of windows code though; for windows to be multi architecture, all of windows needs to work with the new architecture; NT, drivers & userspace.

For Linux, if an existing userspace application doesn't work in aarch64, somebody somewhere will build a port. For windows, so much of their stuff is proprietary that Microsoft are the only ones able to build that port.

Not because "windows bad", just a consequence of such a locked down system which doesn't have anything open source to inherit.

Because it's open source and most of the applications for it are open source. That means you can compile it and the applications specifically for the hardware you have.

Windows does kind of support ARM on its specific hardware, but it can't be adjusted for other hardware and they have to translate most applications to work. Apple has done much of that work for their hardware to work well, as well as very good translation for x86, and because they leaned hard into the transition, developers were mostly forced to compile for ARM going forward. Microsoft hasn't done the same, and ARM is a tiny target, so it doesn't happen with any regularity there.

Because people have been doing so for a long time and have ironed out most of the quirks. The software is also generally quite simple, meaning there are just fewer quirks that need to be ironed out. And the ecosystem is largely open source, meaning everything can be recompiled to target the relevant architecture, so while translation layers are still useful, they're not the essential tool they are in proprietary ecosystems. The main headaches that plague windows on arm mostly just don't exist on the Linux side.

Because it's not developed by some corporate fuckers whose only goal it is to make as much money as possible, it's developed by individual skilled people in their free time, because they're passionate. They don't want to sell some garbage, they genuinely want to make a good operating system for themselves and everyone else to freely use without any restrictions. FOSS is not about the money, it's about actually creating something good.

Because you can try compile it on arm, and if something doesn't work you can report it or fix it yourself. That said windows worked fine on arm years ago. Many gps, medical, and such devices used to use windows ce on arm, mips. (Windows phone too, arm)

ARM the company as well as industry partners contribute code & resources to the linux kernel...so that would be one reason why linux on ARM runs well.

Unsure how we are tracking Microsoft ARM as worse than Linux arm, what benchmarks did we see?

The Raspberry Pi is an exception. It has taken until 2021-2022 for things like video acceleration to work using the normal Linux kernel (not the Raspberry Pi customised one with patches that only that kernel uses). For at least half a decade, you needed a custom kernel with device specific patches or the darn thing just wouldn't work.

Now it mostly works, though the RPi people do keep a separate kernel around with a few patches that they consider better than the ones the Linux kernel has merged.

If you take any other device with a similar board (like RPi clones with an m.2 slot) you'll have to mess with special drivers yet again.

Pi-like devices also use a special configuration setup (a fat32 partition with some hardcoded file paths) that normal ARM boards don't use. That's because you need the closed source Raspberry Pi bootloader to actually get the device to boot.

Imagine having to install grub-msi-gaming-laptops-2021 instead of grub in your desktop. Yes, it works, ut It's all custom with special code and tricks. This is also why you can just insert a USB drive and install Linux on PC but need to deal with special images you flash to the SD card for Pi-likes.

A key factor is LINUX has been available for ARM since nearly "the beginning". Unlike Windows, which was basically Intel only for well over a decade, LINUX has had strong support for multiple architectures throughout its lifecycle. As a result, software that grew up within that ecosystem tended to be more agnostic in design which helps porting efforts.