As far as I know, so-called "fat binaries"--executable files that contain machine code for multiple systems--are only really used on Apple PCs, and even there it seems like they only used them because they needed to transition from PowerPC to x86.
These days a lot of software is cross-platform, and it seems like making a single fat binary would be in many ways simpler than keeping track of a dozen or so different downloads for each combination of operating system and architecture, not to mention somehow conveying to the customer which one they want.
I can come up with plenty of guesses as to why this approach never caught on, for instance:
- A lack of cross-compilation tools making multi-OS binaries infeasible
- You need to test the code on each OS anyway, so you already have to have systems that can compile natively for each OS
- Apparently 32-bit programs "just work" on 64-bit machines already
- Dynamic linking works differently on each OS, so a "fat library" might not work even if a "fat application" would
But since I always work with a library or framework that hides all these OS-specific and architecture-specific details from me, I don't know how true any of that really is, or if there are even more issues I don't know about. So, what are the actual reasons why fat binaries aren't generally used to create multi-architecture and/or multi-OS software? (outside of Apple)