1) Actually Portable Executables, a clever way of formatting a program so that all four OSes interpret it a valid program in their own format.
2) Cosmopolitan libc, a library for communicating with the OS that handles each OS's interface, allowing programs to work on all four.
$ wget https://justine.lol/redbean/redbean-2021-02-27.com
$ unzip -vl redbean-2021-02-27.com
Archive: redbean-2021-02-27.com
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
426 Defl:N 215 50% 02-09-2021 09:24 f9cc9464 tool/net/redbean.css
896 Defl:N 509 43% 02-09-2021 09:24 eb74f8a0 tool/net/redbean.html
16958 Defl:N 6093 64% 02-09-2021 09:24 6a76bd39 tool/net/redbean.ico
5073 Stored 5073 0% 02-09-2021 09:24 86c2afe6 tool/net/redbean.png
554 Defl:N 285 49% 02-09-2021 09:24 0aa6870a usr/share/zoneinfo/Beijing
2335 Defl:N 1093 53% 02-09-2021 09:24 6ccd4450 usr/share/zoneinfo/Berlin
2453 Defl:N 1170 52% 02-09-2021 09:24 7fed6d80 usr/share/zoneinfo/Boulder
...
Also...given that AMD exists and the x86 instruction set is not some magic potion ingredients...
Each individual function is probably on the order of a few dozen machine instructions. Let's say there's 30 such functions that are implemented and 7 OSes to support. 36307 is about 7500 instructions. The average instruction length on x86-64 is 2-3 bytes. So maybe it ends up around 20KB of code space for a program that uses every possible operating system feature that's implemented?
I haven't looked at the implementation. I wonder how it selects between OS implementations. Does it switch on every system call, use a function pointer table, or do some sort of clever in-memory code rewriting?
Speaking of deprecating it, it might be one scenario, but developers probably don't just choose Electron because it is platform independent. I mean, there were other frameworks that supported that use-case even before Electron (e.g. QT). However, what is specific to Electron, is that you can use web technologies to build Apps. But that is also nothing you can do with APE.
So as much as I like to see one binary format for many operating systems, I doubt that it will change anything regarding the Electron problem.
There certainly multiple ways of solving it, but in my opinion, Apple and Microsoft must come to a common ground and support some kind of web-view that is built-in to the OS and extended with a platform independent API for the things that normal browsers do not support/allow, like filesystems access.
At some point both supported the Progressive Web App (PWA) movement for a while, but afaik Apple is the one holding it back at the moment. My guess is that they saw their App-Store business at risk. And even if PWAs were a thing, they are still some use-cases they can not cover in the current state (e.g. missing filesystem access).
Meanwhile Cosmopolitan doesn't provide a portable GUI toolkit so it can't replace electron on its own. Maybe if you could package Cosmopolitan + Qt or something like that you could end up with something very interesting though.
Likewise for non-GUI apps, like command-line utilities that are implemented with NodeJS. As prior art, Fabrice Bellard's QuickJS is able to compile JS programs to spit out a native binary that requires no external qjs runtime. If you modified it to output Actual Portable Executable binaries instead, it would be even more portable than the programs installed with `npm install`.
I've done some experiments and progressed to writing tooling that approaches that I-want-ridiculous-portability problem differently. It doesn't use APE, so it still requires a separate interpreter (such as NodeJS) capable of executing the compiled output, but the object files it outputs are such that even if you don't have a copy of NodeJS installed on your system (or the right copy of NodeJS installed), then you can piggy back off the interpreter built in to your browser. You get a similar double-click-to-run experience, but when you do double-click to run, it launches in the browser, and you can go from object file to modifiable source trivially, since the object file and the Git repo from which it is built are automorphisms. The downside, if you consider it one, is that it doesn't work with arbitrary NPM modules. You have to really buy in to the scripting language dialect and the development philosophy to get anything out of it.
It would be interesting the use the QuickJS+APE strategy above so that there is _no_ reliance on an external interpreter, at the cost of marrying yourself to x86 and introducing some small hurdles in the path to modification and also giving up the safety of the browser sandbox, since you're back to running arbitrary executables.
Then she wrote a standard C library that detects which OS you're using at runtime and branches to the appropriate implementation, allowing the same x86_64 code to run on any supported system.
if (IsWindows())
DoWindowsThing();
else
DoUnixThing();
You might want to ask the thousands of Electron App users how much they care about dead code ;-)
I mean, you are right. But if you offer your users no alternative they might not care enough to choose another product. In addition, some might even value it not having to choose the right binary for their system.
Yes. The true innovation that made all this possible is the novel Actually Portable Executable (APE) format. This means there's no need to choose: Windows will read it as a valid PE file while Linux, the BSDs and Mac will read it as a valid ELF program.
Having code for all operating systems in the executable has always been possible. It's just that before APE there used to be no point. Windows simply isn't able to load and execute an ELF program even if there is Windows code in it.
ELFs would be incompatible even between Linux, Mac and the BSDs since they would almost always depend on very different dynamic libraries. Cosmopolitan fixes this by providing a standard C library with support for everything. I assume incompatibilities can still be introduced by linking against other libraries.
You might be right though. The author might be very good at executable hacks but they're a terrible writer. Their explanation explains nothing.
> Here's how it works:
>
> MZqFpD='
> BIOS BOOT SECTOR'
> exec 7<> $(command -v $0)
> printf '\177ELF...LINKER-ENCODED-FREEBSD-HEADER' >&7
> exec "$0" "$@"
> exec qemu-x86_64 "$0" "$@"
> exit 1
> REAL MODE...
> ELF SEGMENTS...
> OPENBSD NOTE...
> NETBSD NOTE...
> MACHO HEADERS...
> CODE AND DATA...
> ZIP DIRECTORY...
Ok well that clears it up. MZqFpD='. Of course!