Why didn't Microsoft went the Universal Binary way like Apple did? Does anyone knows why the Windows binaries have to be specific to each platform?
https://forum.obsidian.md/t/obsidian-for-windows-1-6-5-insta...
Im not sure how it differs technically from macos universal binaries but the user experience is basically the same - one download no matter what architecture you are on.
This only works if your installer framework (InstallShield, MSI, Wix, Advanced Installer, ClickOnce, etc.) supports such a trick. If it doesn't, you're forced to ask users on the download page which version they want.
If the users guess correctly, it's great. If the ARM users guess x64 incorrectly, it still works. If the x64 users click the ARM version by mistake, they will be greeted with a warning, from Windows, saying this software does not work on their device. This is technically correct but a conversion killer. The odds of this happening are also much larger than 1%, in which case, offering an ARM download is actually likely to be financially harmful on a business level.
(The smartest way of handling this I've seen is to only offer an x64 download, but your app's auto-updater "updates" your app to ARM in the background as though it were an app update. Good luck convincing developers to write all the logic for that though, on top of an existing most-likely-third-party update system, for such a niche market.)
macOS fat binaries are not actually mach-o "binaries", but they are really just an "archive file" which contain multiple files within them. When you execute one, the OS gets to pick which file to use. When you dlopen, it picks the right one, and so on. That's basically the long and short of it.
But an important aspect to note of the macOS design is that "fat binaries" would not work on systems that do not implement support for it. For example, I'm not sure Mac OSX 10.3 (Panther) had support for fat binaries, but 10.5 (Snow Leopard) added them when the Core 2 x86_64 transition happened. This is obvious when you think about it for a second, but here's the key: macOS users actually upgrade their operating systems, quickly. What that means in practice, I think, is that if you started publishing fat binaries with multiple architectures, you could be reasonably sure that within, say, 1-2 years, 99% of your users will be using an operating system that will support fat binaries. The transition window where you need to support the old stuff for Panther users is there, but it's a small window in the grand scheme.
Now think about how it works on Windows. Windows has been using the PE format for decades, and it does not have any notion of "separate sections for separate architectures" (just like Mach-O.) So, if you wanted "fat PEs", you'd need to introduce an entirely new executable format. But you can't introduce new executable file formats for Windows 8, just like how Apple couldn't add fat binaries to Panther. But millions of PCs still run Windows 8, whereas Panther was obsolete within a very short timeframe.
So, if developers start publishing "Fat EXEs" that were actually in a different non-PE format, then you're not going to be able to use those on any older operating system. And the support gap for Windows is significantly larger, so you'd be supporting the transition for potentially many years depending on your userbase. That's a significantly different trade off compared to what MacOS developers and users might stomach.
That said, they could still add support for "Fat PEs", and it would be great. But given the above calculus, I can see why they might not have gone this route, at least initially.
This is my best educated guess and I don't know anyone who could confirm this kind of thing, but that's my 0.02c.
Mach-O fat binaries date back to NeXT though, since NeXTSTEP ran on many architectures (there were quad-arch apps back then which ran on i386, m68k, hppa, and sparc).
Couldn't the ARM code be put at the end of the x86 code, so operating systems unaware of the change would run the x86 code like before, but the ARM devices shipping an updated version of the OS would skip to the ARM code.