A toolchain, one libc with libc++, application libraries, and a graphics engine. Linux, Windows, macOS and Android build from the same code. You do not install a Windows SDK or an NDK for that.
The compiler, the linker and make ship inside the toolchain. Nothing else to install first.
MIT, no royalties
How to create a project, build it and choose a system is written in the repository. Open the source and ask. The agent answers from that.
The toolchain carries the compiler, the headers and the libraries. A vendor SDK shows up only if you choose the build that uses one.
x86_64, arm64 and riscv64, glibc and musl. Calls go to the system libc. We do not stack a second one on top.
x86_64 and arm64. Our own libc on mimalloc, no UCRT and no Windows SDK. System DLLs are bound through our import.lib.
x86_64 and arm64. The +sprt build does not need the macOS SDK. The plain Apple-SDK build still asks for it — that is their license, not ours.
arm64, armv7, x86 and x86_64. There is a sysroot that does not need the NDK. If you already have the NDK, that build works too.
WebAssembly, Embox and NuttX are separate targets. iOS is a toolchain sysroot only: no runtime there yet, and no +sprt variant.
From your code, Linux, Windows, macOS and Android look the same. You do not grow a forest of #ifdef because the CRT differs.
On Linux, Android and macOS, calls go to glibc, musl, Bionic or libSystem. On Windows the libc is ours. time_t and off_t are 64-bit everywhere. A call the OS does not have stays in the headers and returns ENOSYS.
A normal pthread on every system. A priority-inheritance mutex sits on futex, WaitOnAddress or os_sync, depending on where you run.
The runtime itself is built on a small sprt/cxx: no exceptions, with Status and Result. Application code gets a real std:: from a port of LLVM libc++. It lives in std::__sprt, so it does not clash with someone else's libc++.
Timers, sockets, files and processes go through one Looper. Under it: epoll and io_uring, IOCP, kqueue or ALooper. Windows and displays sit behind that API too, not behind a vendor SDK's headers.
On top of the runtime are the libraries an application usually grows around it. They are not wrappers over a platform SDK.
One Value container writes JSON, CBOR and a URL-safe format of our own. LZ4 compression, and the reader detects the format.
SQLite and PostgreSQL through the same schemes: objects, files, a role on each operation, keyset pages. Full-text search in 23 languages, including an in-memory index when there is no server.
HTTP/2 and HTTP/3 through curl. OpenSSL, GnuTLS and mbedTLS: RSA, ECDSA, EdDSA, GOST 34.10, 34.11 and 34.12, JWT.
Read PNG, JPEG, WebP, GIF and TIFF. Write PNG, JPEG and WebP. Vectors are tessellated for the GPU. Fonts are FreeType and HarfBuzz, variable fonts included.
HTML and EPUB with our own layout: blocks, floats, tables, a table of contents. Markdown and Pug templates too.
Our own zip, a filesystem, and guest WebAssembly on WAMR. Graphics are not exposed to guest code yet.
A frame is a graph of passes and resources. The engine inserts the barriers and the layout transitions. Graphics and compute can share one graph. A new frame is built only when the scene changes, so an idle window does not burn the battery.
The main one. On macOS that is MoltenVK, with the portability subset, loaded from your .app.
A separate macOS backend. It does not go through Vulkan.
For boards with no usable Vulkan: Mali, VideoCore, older Android, emulators.
Native, and in the browser through the WebAssembly build.
Flat 2D with no driver and no shaders. No compute, no depth, no MSAA on this one.
Wayland and X11 (Linux picks at startup), Win32, Cocoa, Android, and a headless mode. Flexbox and grid, gestures, vectors, and text that lands a glyph on a pixel.
The installer sets up the toolchain and creates a first project.