> This is an idea whose time has come; POSIX even changed their rules about binary in shell scripts specifically to let us do it.
> Jilles Tjoelker from the FreeBSD project played an instrumental role in helping me to get the POSIX rules changed to allow binary in shell scripts, which is what made this project possible.
but that's not true, as recently discussed here: https://news.ycombinator.com/item?id=41636569
A Win32 program will not run out of the box on either Linux or macOS. Neither will a Java app.
The nice thing about Cosmopolitan is that it "just works" as far as end user is concerned. But without firm support from the OSes involved, it is inevitably a hack with questionable long-term stability prospects.
What we really need is some kind of standardized low-level (think LLVM bitcode or wasm) architecture- and platform-agnostic binary format that can be JIT-compiled to the same native code that a C compiler would have produced from the source. And that is supported by all major OSes out of the box.
And stuff like https://github.com/jart/cosmopolitan/issues/1263 shows that just because it works today, it doesn't mean that it'll work tomorrow. What's the guarantee that the same won't happen on Linux or macOS eventually?
Don't get me wrong, APE is a hell of a hack, and I love it for that. But it can't be a truly stable platform without guarantees from the underlying OSes to keep all of that machinery working the same way. And if we could actually get them to agree on something like that, why not get them to agree on an actual portable executable format that is future-proof also wrt new CPU architectures?
(Note, by the way, that this is orthogonal to the whole notion of fat binaries that contain arch-specific code. That is still a useful optimization to have in practice even if one has portable bytecode, alongside said portable bytecode.)
- With Windows, APE is just PE and WIN32 so those are already guaranteed by Microsoft.
- With Linux, I've been working with kernel maintainers to build consensus around around a patch https://justine.lol/ape.patch that will let your APE binaries be loaded by binfmt_elf. This will provide you with a guarantee that they'll still work, even if someone has for instance registered a binfmt_misc entry like WINE that's intercepting MZ executables.
- With FreeBSD, I'm also working to build consensus here around another patch, that will help the kernel load APE natively as a normal ELF executable. That means you won't need to rely on the system shell to load your program into memory.
- I've been writing a specification for APE that documents this file format, its ABI, and its historical encodings. https://github.com/jart/cosmopolitan/blob/master/ape/specifi...
One day in the future, when we have the support of major OSes for the native loading of portable binaries, we'll look back at the APE shell script bootstrapping process similar to how we look back at self-extracting zip archives. When Phil Katz first invented PKZIP, it was useful to prepend the software to each archive. But nowadays it isn't necessary, since all OSes come with support for PKZIP built in.
That said, a fat binary format that works for both Windows and Linux is already very useful.
Case in point:
https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s...
The system call numbers of all the unixlikes are bitwise packed into a single number. There is exactly one of those columns which is stable: the Linux one. Everything else is not part of the binary interface of their respective operating systems.
I've written about how Linux is special in this regard:
https://www.matheusmoreira.com/articles/linux-system-calls
It's a neat hack but I'm afraid it's in grave danger of falling victim to the Darth Vader of OS ABI stability.
https://lwn.net/Articles/806870/
Program to the API rather than the ABI.
When we see benefits, we change the ABI
more often than the API.
I have altered the ABI.
Pray I do not alter it further.
-- Theo de RaadtThe more difficult problem with cross plattform apps are always native look and feel and calling native apis in an idiomatic and performant ways.