return to table of content

Cosmopolitan v3.5.0

trustno2
18 replies
10h21m

I'm always somewhat scared - not sure if rationally or irrationally - about cosmopolitan.

It's a cool hack but I somehow feel like it should not work.

alganet
8 replies
9h33m

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

3836293648
5 replies
6h26m

Working across unices is reasonable. Adding Windows is less so

flohofwoe
2 replies
3h39m

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.

vidarh
0 replies
2h22m

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.

boricj
0 replies
2h51m

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.

cpach
0 replies
6h12m

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.

TimTheTinker
0 replies
2h59m

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
0 replies
3h2m

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
0 replies
7h55m

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

asveikau
5 replies
3h58m

Years ago I read some of the author's posts (they're active on HN too iirc) about it, and it seemed to me like they were relying heavily on the internals of the loader or dynamic linker on each platform, such that a new release for any given OS could conceivably break your binary.

It's probably a very fun project to hack on but I would advise against distributing the binaries and expecting them to work over the long term.

TimTheTinker
4 replies
3h25m

To my recollection, at least on *nix operating systems, they got some changes made to the POSIX standard to formalize behavior the binaries rely on. So going forward, mere POSIX compliance and ongoing ABI compatibility guarantee the binaries will continue to work on *nix operating systems.

On Windows, backwards ABI and executable compatibility has always been an extremely high priority, so I think the danger of future breakage is low.

Neither of those speak to macOS, but maybe someone who knows more can help clarify.

asveikau
3 replies
1h59m

I disagree with your assessment in all cases. You simply do not know what you were talking about.

Standardization efforts and backward compatibility assumes a well-behaved application. If you explicitly depend on really weird hacky stuff like abusing corner cases in the object file format, you risk breakage and you will break.

In the Unix world, firstly, platforms that aren't Linux typically say that if you don't do syscalls through system libc, all bets are off. Second, if they standardized a few things here and there, they are likely standardizing stuff that will formed applications linked with typical libraries will exercise. Standardization does not imply explicitly listing all possible corner cases of your object file format.

On Windows, I happen to be a former Microsoft dev who worked on Windows in 2008-2011. If an app were trying to push the limits of the PE format, I don't think it would get fixed on the platform side... I've seen popular applications do much less bad things and get broken.

yjftsjthsd-h
1 replies
1h42m

I disagree with your assessment in all cases. You simply do not know what you were talking about.

No need to be rude.

Standardization efforts and backward compatibility assumes a well-behaved application. If you explicitly depend on really weird hacky stuff like abusing corner cases in the object file format, you risk breakage and you will break.

Sure, but if you get the standard to include your use then it's not a hacky edge case anymore. Ex. https://justine.lol/cosmo3/ "POSIX even changed their rules about binary in shell scripts specifically to let us do it" > https://austingroupbugs.net/view.php?id=1250

jart
0 replies
1h17m

Cosmo author here. Could you please clarify what specific object file features we're abusing? The only hacky thing I did was remove the shebang line, and POSIX was awesome enough to change their rules to let us do it. https://austingroupbugs.net/view.php?id=1250 Beyond that, we just depend on stable ABIs and APIs. We don't link NTDLL for example. It's just straight up WIN32. On MacOS ARM we use the dynamic linker. I want Cosmo programs to stand the test of time. That's why I stopped building apps with NodeJS and wrote this instead. The whole reason this release is on the HN front page, is probably because it got rid of MAP_FIXED mappings and page size assumptions. So if you can tell me where we're still exposed, then I'd love to fix it. Thanks!

mgaunard
0 replies
9h25m

It doesn't really work, the libc is widely non-conforming.

I'd rather have a proper interface designed for portability rather than a hacked-together POSIX-but-not-really.

hiAndrewQuinn
0 replies
10h3m

I'm somewhat of the same mind, but I'm fairly sure a study of Operating Systems: Three Easy Steps would get me over the hump. There's no actual reason to suspect this thing would like, sidestep normal process management or memory virtualization or something and run amok... I think.

boricj
0 replies
3h5m

You can commit a lot of sins with ABIs if you throw the academic books into the fire.

For example, on my side I'm developing tooling that allows one to delink programs back into object files. This allows me to commit a whole bunch of heresy according to CS101, such as making a native port of a Linux program to Windows without having access to its source code or taking binary code from a PlayStation game and stuffing it into a Linux MIPS program.

When you're doing that kind of dark magic, it's one of those "know the rules so well you can break them" situation. Instead of following the theory that tells you what you should do, you follow the real-life world that constrains what you can do.

WantonQuantum
16 replies
11h31m

I assume the executables won't run on ARM platforms? So modern Macs are out, etc.

lukemerrick
5 replies
11h20m

Looks like there is both an ARM and x86 version according to the docs. Probably need two different binaries, but you still get cross-OS for each architecture.

eesmith
4 replies
10h38m

It's a single binary, cross-OS, cross-arch.

Go to https://cosmo.zip/pub/cosmos/bin/ and download an executable, like https://cosmo.zip/pub/cosmos/bin/basename .

  % curl -O https://cosmo.zip/pub/cosmos/bin/basename
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  100  663k  100  663k    0     0   440k      0  0:00:01  0:00:01 --:--:--  441k
  % chmod +x basename
On macOS with an M1:

  % arch
  arm64
  % sha256sum basename
  2e4cf8378b679dd0c2cdcc043bb1f21eaf464d3c3b636ed101fbc5e3230eb5fb  basename
  % file ./basename
  ./basename: DOS/MBR boot sector; partition 1 : ID=0x7f, active, start-CHS (0x0,0,1), end-CHS (0x3ff,255,63), startsector 0, 4294967295 sectors
  % ./basename /dev/null.txt
  null.txt
On FreeBSD with an amd64:

  % uname -sm
  FreeBSD amd64
  % sha256sum basename
  2e4cf8378b679dd0c2cdcc043bb1f21eaf464d3c3b636ed101fbc5e3230eb5fb  basename
  % file basename
  basename: DOS/MBR boot sector; partition 1 : ID=0x7f, active, start-CHS (0x0,0,1), end-CHS (0x3ff,255,63), startsector 0, 4294967295 sectors
  % ./basename /dev/null.pdf
  null.pdf

alganet
3 replies
10h19m

Kind of. It can be read as a single binary, some supported systems will do that. In others, the executable is first parsed as a shell script. There's definitely more to it than a single binary.

    MZqFpD='

     ø        @               ' <<'justine0e5c7z'
    È  ²@ë 됐ëHƒì1Ò½  ëéE  ü‡>à¿ p1ÉŽÁúŽ×‰Ìûè  ^îr ¸ PP 1ÿ¹ ó¤‡ÒÿêŽ   ŽÙ¹ ¸P ŽÀ1À1ÿóª€ú@tè  °1É0ö¿Pèo ŒÆƒÆ ŽÆOuóê '  SR´Ís1ÀÍrF¸¹ ¶ » ŽÃ1ÛÍr3´Ír-ˆÏ€ç?€áÀÐÁÐÁ†Í1öŽÆ¾‡÷¥¥¥¥¥¤“«®‘«’«Xª’[ÃZ€ò€1ÀÍr÷ë¡PQ†ÍÐÉÐÉÁ1Û°´ÍYXrþÀ:$v
    °þÆ:6)v0öAÃP1ÀÍXë̉þ¬„Àt »  ´ÍëòÃW¿¹&èèÿ_èäÿ¿Á&èÞÿóëü¹ ¾ ­…Àt
    QV—¾Ð&è ^YâîÉú…ÒtRV1ɱʬ^ €îZ¬îBIyúà              €  ÿÿÿ    ÿÿÿÿ                                                Uª
    justine0e5c7z
    #'"

    o=$(command -v "$0")
    [ x"$1" != x--assimilate ] && type ape >/dev/null 2>&1 && exec ape "$o" "$@"
    t="${TMPDIR:-${HOME:-.}}/.ape-1.10"
    [ x"$1" != x--assimilate ] && [ -x "$t" ] && exec "$t" "$o" "$@"
    m=$(uname -m 2>/dev/null) || m=x86_64
    if [ ! -d /Applications ]; then
    if [ x"$1" = x--assimilate ]; then
    if [ "$m" = x86_64 ] || [ "$m" = amd64 ]; then
    exec 7<> "$o" || exit 121
    printf '\177ELF\2\1\1\11\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0vE@\0\0\0\0\0\510\013\000\000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\100\0\70\0\006\000\0\0\0\0\0\0' >&7
    exec 7<&-
    fi
    exit

bux93
2 replies
8h39m

Reminds me of a cool tool I once used, uudecode.com, which was a DOS binary that only used 7-bit characters and could decode uuencoded (base64 predecessor) files. Was useful for getting attachments through e-mail in the face of all kinds of filters.

d4rti
5 replies
11h19m

Works for sure:

  $ file ./bin/python
  ./bin/python: DOS/MBR boot sector; partition 1 : ID=0x7f, active, start-CHS 
  (0x0,0,1), end-CHS (0x3ff,255,63), startsector 0, 4294967295 sectors

  $ ./bin/python
  Python 3.11.4 (heads/pypack1:6eea485, Jan 24 2024, 10:14:24) [GCC 11.2.0] on 
  linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> platform.processor()
  'arm'

4gotunameagain
3 replies
8h49m

Out of curiosity, why are you running python packed with cosmopolitan ?

simonw
2 replies
6h45m

Presumably to demonstrate that it works on Mac ARM platforms, in response to the question about that.

4gotunameagain
1 replies
5h55m

If was satisfied with my own presumption I wouldn't have asked ;)

simonw
0 replies
5h5m

That Python app is a popular demo for Cosmopolitan. It's what I would have chosen for that demo, too! It's handy because it outputs a little bit of information about the current architecture on the first line when you start the shell.

There's some interesting background on it in this issue: https://github.com/jart/cosmopolitan/issues/141

smcameron
0 replies
6h23m

I forget how I did this, but:

    $ file hello.com
    hello.com: αcτµαlly pδrταblε εxεcµταblε

nabla9
1 replies
11h24m

It works on AMD64 and ARM64 both.

It makes two architecture fat binary, but removes all code not needed. Resulting binary is typically only 30-50% larger than 1-architecture binary.

jart
0 replies
49m

Is that an embedded device with a small address space? APE used to require a 47bit address space. The release I published today fixes that. Maybe give it another try?

auggierose
15 replies
10h8m

Is there a UI library that goes with that?

DrNosferatu
7 replies
9h11m

A Web Interface for Cosmopolitan Apps would be a great bridge for an UI.

auggierose
5 replies
9h10m

I am looking for an Electron replacement for writing my apps. Could cosmopolitan be the basis of something like that, or is that not really its purpose?

brabel
2 replies
8h8m

Lua is perfect for Redbean because it's tiny and made for embedding, which is this exactly use case. Something like TypeScript would require a transpiler to JS and a JS runtime, which as far as I know, even the smallest one would be much bigger than Lua. And Lua has well defined semantics to call C and be called by C, which may be hard to do with JS/TS.

DrNosferatu
1 replies
7h59m

Any examples and good tutorials on how to best go about it?

brabel
0 replies
2h39m

Best go about using Redbean? The project is well documented: https://redbean.dev/

Just go through it, it answers all questions you may come up with IMO.

Or you mean about embedding Lua? The official docs are great too: https://www.lua.org/pil/24.html

If you prefer a tutorial, there's plenty as Lua has been around for a long time. Search on Youtube for example and there's lots of videos.

The top hit on DDG for me was https://lucasklassmann.com/blog/2019-02-02-embedding-lua-in-... which seems pretty straightforward to follow.

stutonk
0 replies
2h34m

quickjs [1] has native support for Cosmopolitan, is meant to be easily embeddable, and is included as part of the standard Cosmopolitan distribution. It looks like qjs also has patches for recent-ish versions of the Typescript compiler as well. Someone has made a nodejs-style project called txiki.js [2] using vanilla qjs. Maybe it would build with Cosmopolitan with some tweaking. But if you're thinking of packaging a whole browser engine like Electron that might be a Sisyphian effort.

[1] https://bellard.org/quickjs/ [2] https://github.com/saghul/txiki.js/

airstrike
0 replies
2h0m

I would suggest iced if you're ok with Rust https://github.com/iced-rs/iced

It's amazing, but I should warn documentation right now is not quite thorough

lxgr
0 replies
3h58m

Llamafile does that (i.e. it hosts a local web server that presents a GUI).

BiteCode_dev
6 replies
9h1m

I would use redbean, from the same author, and use HTML.

auggierose
4 replies
8h49m

Impressive stuff. Unfortunately, Lua. From a user point of view (well, at least this user), TypeScript would be a better fit.

ukuina
3 replies
6h37m

What are your misgivings about Lua?

giraffe_lady
0 replies
3h49m

Lua is too bare bones. It's a carefully considered tradeoff for the project goals of being a very small & easily embeddable language for C projects, but it means you need to implement too much load-bearing functionality yourself. Each lua project ends up being an ad hoc framework composed of C bindings and standard lib extensions, but it doesn't have an ecosystem that makes this straightforward or consistent.

A lot of people like lua from using it on very small projects, or like, spiritual reasons related to its implementation simplicity. But having used it quite a lot professionally, in practice it ends up being a slog to work with.

All that said, lua is closely tied to C, and embedded in a C project is both its intended use and the place where it fits best. So while I don't really like lua and would almost never choose it myself, this is one of the rare exceptions where I think it's a good choice.

A lot of people want redbean to use TS or python instead, and imo either would make it much bigger, more complex, for relatively little benefit. It would definitely benefit from a more full-featured language, but I think a weirder one that is still intended for embedding in C would be best. Something out there like janet or fuck it, tcl. But lua has a lot of allure for a lot of programmers and I think gives the project a feeling of "old school cool" while still being pretty accessible. So is probably the best choice in the end.

auggierose
0 replies
3h11m

None in particular, except that all the code I am currently writing is in TypeScript. Especially if it comes together with HTML files.

NateEag
0 replies
5h42m

Not OP, but having written some Lua, I can make some guesses:

- Relatively obscure language, so potential contributor base is limited from the start

- Lua shares PHP's "One datatype to rule them all" design, which works but feels ugly. In PHP it's "arrays", in Lua it's "tables", but either way you have all the attendant problems and weird edge cases to learn

- Expanding on above point, Lua's APIs for working with tables are, uh, idiosyncratic. Slicing a "list", last I looked, was an unintuitive monstrosity like `new_table = { table.unpack(old_table, start_index, length) }`

I could keep going, but I have other things to do during my brief time in this universe.

To any Lua aficionados out there, my apologies if I've misrepresented it. Corrections to my misunderstandings will be appreciated.

phkahler
0 replies
4h31m

> I would use redbean, from the same author, and use HTML.

Wait... Could we build Solvespace web version and bundle it into that and have a completely portable CAD program that runs locally but in the browser?

pixelpoet
0 replies
3h55m

I thought I was alone!! wipes tears of joy

lioeters
0 replies
8h16m

I have found my people.

cgh
0 replies
4h1m

Amazing, thank you for this.

tiffanyh
2 replies
3h15m

It's a bit easier to do when you don't limit yourself to exactly 80-char per line

  Those commits were 
  72-chars per line.
  Which is easier to
  do than EXACTLY 80
  character per line

layer8
0 replies
1h48m

72 characters is the standard limit for Git though. This convention has a long tradition from the text-mode days of email and Usenet in 80-column terminals/screens, where 72 characters allowed for the addition of a reasonable number of quoting levels (indicated by prefixing quoted lines with “>”), and/or for other line markers, before exceeding the screen width and having to reformat.

lproven
1 replies
7h6m

Back in the pre-GUI era, I did this with all my posts and comments online. All fully-justified, both margins, without any extra whitespace: just careful choice of words, and occasional (but always normal standard) abbreviations.

It was fun, once practised it barely slowed me down, and when people noticed it blew their minds.

Then along came GUIs and proportional fonts and made it all invisible. :'(

ramses0
0 replies
2h32m

cfg.linebreaks: LLM-plain-tex

/s

neerajk
0 replies
4h13m

We'll give "real actual bug" a pass :)

meisel
6 replies
4h11m

Although this project is undoubtedly very cool, and maybe simplifies build processes by having a single binary, is there any other reason to use it? How does it compare in terms of performance, static linkability, standards conformance, etc. with musl and glibc? I’m curious because I’m picking a libc at the moment for my project.

tracker1
2 replies
2h32m

I don't know enough to compare to musl, but I suspect being ISC licensed (similar to musl's MIT license) allows for static linking without upstream impact such as GPL.

Would be curious regarding features and performance comparisons with musl, which seems to come up a little short compared to say gnu libc.

saghm
0 replies
1h58m

I suspect parent commenter isn't just asking about static linking from the perspective of licensing but about technical feasibility; at least part of the reason people use musl is that static linking glibc isn't well supported.

jart
0 replies
1h41m

Cosmo author here. We used to build our code with musl-cross-make. Once Cosmopolitan got good enough that we could compile GCC using Cosmo, our build latency dropped in half. https://x.com/JustineTunney/status/1726141024597324189

Cosmopolitan Libc is 2x faster than Musl Libc for many CLI programs like GNU Make and GCC because it has vectorized string libraries like strlen(). Musl won't merge support it on x86. I even mailed Rich patches for it years ago.

Cosmopolitan's malloc() function is very fast. If you link pthread_create() then it'll create a dlmalloc arena for each core dispatched by sched_getcpu(). If you don't use threads then it'll use a single dlmalloc arena without any locking or rdtscp overhead.

Cosmo has pretty good thread support in general, plus little known synchronization primitives from Mike Burrows. You can do things like build a number crunching program with OpenMP and it'll actually run on MacOS and Windows.

Cosmopolitan plays an important role in helping to enable the fastest AI software on CPUs. For example, Mozilla started an open source project called LLaMAfile a few months ago, which runs LLMs locally. It's based off the famous llama.cpp codebase. The main thing Mozilla did differently was they adopted Cosmopolitan Libc as its C library, which made it easy for us to obtain a 4x performance advantage. https://justine.lol/matmul/ I'm actually giving a talk about it this week in San Francisco.

jart
0 replies
1h27m

You're basically just benchmarking the WIN32 filesystem versus a Linux VM in that case. The Windows file system is famously slow. It'd make more sense to compare a Cosmo binary running on WIN32 with a WIN32 native program. For example, Emacs has a WIN32 port where they wrote all the Windows polyfills on their own, and because they aren't experts on Windows, the official GNU Emacs Windows releases go a lot slower on Windows than if you just compile Emacs from source on Linux using Cosmo and scp the the binary over to run on Windows. See https://justine.lol/cosmo3/

yjftsjthsd-h
0 replies
1h48m

I would argue it's less about the build process and more about the user experience - no install, no "pick the right binary for your platform", just "download this file and run it". I don't think it's literally a static binary, but on anything but a `FROM scratch` container it might as well be.

Also I think there were some numbers showing that it sometimes had better performance than alternatives, but I can't seem to find the post right now.

morbicer
0 replies
1h21m

Wow this is awesome, thanks for the tip

ncruces
1 replies
2h23m

Having written a portable SQLite VFS from scratch, I'm a bit scared of how they blindly translate fcntl locks into LockFileEx in a forking web server.

The opportunity for data corruption just freaks me out.

jart
0 replies
14m

This is a legitimate criticism. You should not use Redbean to host a production SQLite server on Windows. Redbean + Windows + SQLite should be considered something fun for personal use cases at best. In general though Redbean was never intended to be an production system. Its logo is after all a photo of a toy. But if you're going to run it in prod anyway, then please use UNIX folks. We spent a lot of time making sure system calls like fsync() will behave the way the SQLite authors intended across the various flavors which have a surprising amount of depth, although not quite so bad a horror show as Windows file locks.

j16sdiz
4 replies
7h0m

in release note:

... , it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format ...

Did POSIX really _approve_ this? if yes, when?

oguz-ismail
2 replies
5h18m

POSIX now says:

The input file can be of any type, but the initial portion of the file intended to be parsed according to the shell grammar [...] shall not contain the NUL character.

But the initial portion of, https://cosmo.zip/pub/cosmos/bin/cat for example, does contain the NUL character.

jart
1 replies
56m

Cosmo author here. I'm familiar with the new rules. They were first implemented in https://github.com/freebsd/freebsd-src/commit/e0f5c1387df23c... which makes a clear intentional allowance for what APE is doing. If you look at the hex dump:

    main jart@luna:~/llamafile$ hexdump -C cat | head
    00000000  4d 5a 71 46 70 44 3d 27  0a 0a 00 10 00 f8 00 00  |MZqFpD='........|
    00000010  00 00 00 00 00 01 00 08  40 00 00 00 00 00 00 00  |........@.......|
You'll notice there's no NUL characters on the first line, and that the subsequent NULs are escaped by a single-quoted string, which is legal. The rules used to be more restrictive but they relaxed the requirements specifically so I could work on APE. Jilles Tjoelker is one of the heroes who made that possible.

oguz-ismail
0 replies
27m

[T]he initial portion doesn't mean the first line, it means the script part of a file consisting of a shell script and a binary payload, separated by `exit', `exec whatever', etc. A good example is the Oracle Developer Studio installation script.

You can write to Austin Group mailing list and ask for clarification if you want.

geokon
4 replies
5h3m

It'd be fun/great if someone made Graal Native work with it. Then things could come full circle and I could compile my Clojure/Java binaries to run everywhere (but now without a VM)

simcop2387
0 replies
3h31m

Forget which one, but there's a WASM runtime that's working on running on Cosmo-libc, combined with the WASM graal native port that's going... https://github.com/oracle/graal/issues/3391

sgammon
0 replies
3h20m

work is ongoing

zbendefy
1 replies
6h48m

wouldn't targeting webassembly provide something similiar? how would this compare to targeting WASM and running a runtime like wasmer?

optymizer
0 replies
6h2m

WebAssembly is bytecode that runs on a virtual machine.

Cosmopolitan is a libc replacement. Your program is still compiled to real CPU instructions, which execute much faster.

tarruda
1 replies
1h44m

I wonder if it is possible to have a 100% portable qemu build with this. Would be funny to have a usb stick with qemu + VM that runs on any OS.

jart
0 replies
41m

blink is almost as good as qemu-user and it works great compiled with cosmocc. https://github.com/jart/blink

stephc_int13
1 replies
3h47m

Is there a plan to distribute the cosmopolitan libc without all the APE stuff?

For now it seems to be more like a framework+toolchain than a standalone library.

jart
0 replies
45m

There can be if someone who wants it can help the project get the support it needs to expand in scope. Cosmo has impact and velocity since I only have to get my code to work on GCC 12.3 which produces binaries for all OSes. Occasionally I'll write code like stdckdint.h (https://github.com/jart/jtckdint) that can be consumed by all the cosmocc competitors, e.g. xcode, msvc, etc. but doing that requires a painstaking amount of effort.

m1keil
1 replies
10h57m

Cosmo looks so cool. Are there any big projects out there that use it for distribution?

aidenn0
1 replies
1h50m

I've been following it for almost 4 years now and I still do not know how serious of a project Cosmopolitain/αpε is.

TimTheTinker
0 replies
1h2m

The author is certainly very serious about writing highly distributable production software that works and will continue to work far into the future.

It's already being used for serious things - Mozilla's llamafile and redbean are two examples that come to mind.

dirkc
0 replies
6h5m

I just scrolled for the images, I don't know about reading assembly for fun :)

superkuh
0 replies
4h41m

Any idea if there will ever be a fix for the majority of linux distributions that cannot run cosmopolitan C applications without the bin fmt fix?

modeless
0 replies
1h29m

The commit message for the first commit there says "Actually Portable Executable now supports Android". I assume this means that the bare executables can run on Android kernels, not that there's any support for installing APEs as Android apps. But it seems possible for that to eventually work! Is that a goal of the project?

fusslo
0 replies
1h27m

Never heard of Cosmopolitan before, but can I just say I really appreciate that the FIRST paragraph is a description of WHAT Cosmopolitan is and does.

There's way too many readme's that just jump in and assume the reader already is familiar with the project. it's a pet peeve of mine