Cosmopolitan Libc v2.0 (opens in new tab)

Not _exactly_ what you're asking for, because certainly you're looking for a write-up/blog, however, if you haven't peeked at ape.S you absolutely must:

https://github.com/jart/cosmopolitan/blob/master/ape/ape.S

It is very commented, in a good way.

Sadly not. Everything I've read assumes you are already very familiar with the obsolete executable formats it uses (COM, 6th edition Unix shell scripts).

I presume it uses tricks similar to those files that are both ZIPs and PDFs simultaneously or whatever - basically they've chosen formats where the parser starts by reading different bits of the file.

But that's an educated guess because I don't think there's a clear explanation anywhere.

Yes we actually need to use exponential backoff when calling a lot of WIN32 APIs in our polyfills, due to the way Windows is. There's also layered service providers like Komedia which need to be worked around by a C library implementation. Supporting Windows also means that being falsely accused of being malware is the norm rather than the exception. It got so bad once that Google started delisting our websites. Microsoft even considered our Hello World executables a "severe threat". https://twitter.com/JustineTunney/status/1541801499210092544 The way I fixed it is every time I compile a program I upload it to Microsoft Security Intelligence and ask them to whitelist it. Sometimes I'll just zip up the build output directory into a giant zip file and send them hundreds of executables at once, and they'll whitelist them all. Needless to say, WIN32 related features aren't the highest on our list of priorities right now. We're actively working on getting Microsoft to address their biases regarding open source executables.

Regarding the C:/ vs. /c/ thing, we got away with not caring for the longest time, because our programs are generally designed to (a) always use relative paths, and (b) never call chdir(). However porting Python changed that, since Python likes to be clever with paths. So I'd say it's really the end of a realization, not the start.

Without supporting Windows, the whole thing makes little sense.

I would prefer recommending an openat-style solution where possible.

Having a single global root is in fact bad. Having paths be relative some origin is good. DOS was, in a funny way, ahead of the curve.

No, it isn't. Seven upvotes and zero comments don't count as having had attention. Please read the FAQ linked at the bottom.

We support that. If you want a freedom-optimized build:

    make -j16 MODE=tinylinuxbsd

Will produce ELF executables that run on Linux, FreeBSD, NetBSD, and OpenBSD. You'll never have to worry about being red-flagged by Microsoft. You won't have worry about Apple breaking your binaries. You won't have to worry about Glibc's license or wine binfmt_misc issues. Your binaries will be smaller, starting at 8kb in size. It's real nice and still supports 4x more platforms than the existing tools. If you use it, please note that "tiny" modes disable a lot of cool features like --ftrace and --strace. You can turn them back on by putting:

    ifeq ($(MODE), linuxbsd)
    CONFIG_CPPFLAGS += \
      $(BACKTRACES) \
      $(FTRACE) \
      -DSYSDEBUG \
      -DSUPPORT_VECTOR=113 \
      -O2
    TARGET_ARCH ?= \
      -msse3
    endif

In either ~/.cosmo.mk or build/config.mk. Then you'd say `make MODE=linuxbsd`. We also ship a `tinylinux` prebuilt amalgamation on https://justine.lol/cosmopolitan/download.html

Lastly, you can always change the .com extension to .exe. I would have chosen the latter, but I think UNIX has more in common with DOS than it does with Windows. I know people in the Microsoft camp hold negative associations with .com. But I didn't want people in other camps to think APE is just a Windows program.

APE binaries work out of the box on ARM machines running Windows. https://youtu.be/CQ7Npip88Yw APE binaries work on Apple M1 with Rosetta, but it's not fully tested yet. We're still working on Linux + ARM.

Correct. It's Landlock Make. It does pledge() and unveil() sandboxing. See https://justine.lol/make/ and https://github.com/jart/landlock-make and https://justine.lol/pledge/

Indeed! Try this:

    # git clone https://github.com/cosmopolitan
    # make -j8 o//third_party/python/python.com
    wget https://justine.lol/ftrace/python.com
    mkdir .python
    printf 'print("hello world")\n' >.python/hello.py
    printf -- '-m\nhello\n' >.args
    zip -r python.com .python .args
    chmod +x ./python.com
    ./python.com

This is a great way for white-labeling the APE Python interpreter as your own program. You just put your source code inside the executable using the zip command. Then you add a .args file that specifies the default argv[] array if the user didn't specify any arguments.