4 ms·
I thought the same too, and my best guess would be that: backwards compatibility with older Windows is important, and Microsoft has a much harder time with that
by aseipp 2y ago
I thought the same too, and my best guess would be that: backwards compatibility with older Windows is important, and Microsoft has a much harder time with that than Apple. It's both technical and social.
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.
- mrpippy 2y agoMac OS X 10.3 did have support for fat binaries, it supported both ppc and ppc64 (although there were very few system libraries that could be used from ppc64). 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).
- ChocolateGod 2y ago> 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. 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.
- a1o 2y agoThat is a cool approach. And Windows files already support appending files too - or at least I know exe files do.
- a1o 2y agoI agree with you but Windows Arm has existed for a long time now (remember Windows RT?), Microsoft then lacked the foresight to add this to their system when they should have instead of doing nothing for so long.