5 ms·

It should work. We should have portable executables across many operating systems and architectures. The other expectation is scary.

cpach 2y ago
There’s also Java, Python, Ruby, NodeJS etc etc.
3836293648 2y ago
Working across unices is reasonable. Adding Windows is less so
- cpach 2y ago
  It’s quite rare to ship multi-Unix binaries, isn’t it? Cosmopolitan is a very cool hack indeed, but IMHO it’s not likely to gain widespread usage.
- flohofwoe 2y ago
  A thin POSIX layer and ELF loader shouldn't be too much of a problem for Microsoft to implement if they wanted to do so (WinNT actually did have a POSIX personality at some point, but I don't think that's still supported). I'd also like to see a builtin WASM runtime in all operating systems.
  - boricj 2y ago
    Microsoft did implement a not-so-thin POSIX layer and an ELF loader atop the NT kernel, it's WSL1 (Windows Subsystem for Linux). It was obsoleted by WSL2, which uses a specifically-tuned Linux VM instead for performance and completeness reasons. I haven't played with it, but I think the classic Windows POSIX subsystem used the COFF/PE file formats instead of ELF.
  - vidarh 2y ago
    Indeed, back in '95 or so there was a library called CrossELF that'd let you compile ELF so files and use a tiny loader linked to CrossELF for each platform you cared about to load the main .so file, and you could build platform-independent code with it. I remember writing some simple networking code where the loader just had a tiny set of shims for a few calls and the rest of the networking code was a single binary for both Linux and Win32. The problem is wrapping the relevant APIs - as you can see w/e.g. Wine. For some functionality - like networking - the surface is pretty small, for others its a nightmare.
- TimTheTinker 2y ago
  Creating polyglot source code is a well-studied type of hack. If that's possible, why not polyglot executables? After all, an executable file format is essentially another type of source code. Pair that with a polyglot ABI and polyglot system calls... and you get APE binaries :)
duped 2y ago
Why? Hardware and software architectures often have radically different needs from their loader, it doesn't make sense to have one format to rule them all. And any format flexible enough to support all use cases would just be a container for other formats, and in practice, loaders would ignore the variants that they don't/can't support so developers would need to care about porting things anyway. ELF is pretty stable across many architectures and platforms but it's proven to be inflexible enough for plenty of applications where people develop their own, or alter it in varying ways.

cpach 2y ago

There’s also Java, Python, Ruby, NodeJS etc etc.

3836293648 2y ago

Working across unices is reasonable. Adding Windows is less so

cpach 2y ago
It’s quite rare to ship multi-Unix binaries, isn’t it? Cosmopolitan is a very cool hack indeed, but IMHO it’s not likely to gain widespread usage.
flohofwoe 2y ago
A thin POSIX layer and ELF loader shouldn't be too much of a problem for Microsoft to implement if they wanted to do so (WinNT actually did have a POSIX personality at some point, but I don't think that's still supported). I'd also like to see a builtin WASM runtime in all operating systems.
- boricj 2y ago
  Microsoft did implement a not-so-thin POSIX layer and an ELF loader atop the NT kernel, it's WSL1 (Windows Subsystem for Linux). It was obsoleted by WSL2, which uses a specifically-tuned Linux VM instead for performance and completeness reasons. I haven't played with it, but I think the classic Windows POSIX subsystem used the COFF/PE file formats instead of ELF.
- vidarh 2y ago
  Indeed, back in '95 or so there was a library called CrossELF that'd let you compile ELF so files and use a tiny loader linked to CrossELF for each platform you cared about to load the main .so file, and you could build platform-independent code with it. I remember writing some simple networking code where the loader just had a tiny set of shims for a few calls and the rest of the networking code was a single binary for both Linux and Win32. The problem is wrapping the relevant APIs - as you can see w/e.g. Wine. For some functionality - like networking - the surface is pretty small, for others its a nightmare.
TimTheTinker 2y ago
Creating polyglot source code is a well-studied type of hack. If that's possible, why not polyglot executables? After all, an executable file format is essentially another type of source code. Pair that with a polyglot ABI and polyglot system calls... and you get APE binaries :)

duped 2y ago

Why? Hardware and software architectures often have radically different needs from their loader, it doesn't make sense to have one format to rule them all. And any format flexible enough to support all use cases would just be a container for other formats, and in practice, loaders would ignore the variants that they don't/can't support so developers would need to care about porting things anyway. ELF is pretty stable across many architectures and platforms but it's proven to be inflexible enough for plenty of applications where people develop their own, or alter it in varying ways.