bx: a base library for cross-platform code that avoids the CRT

Two goals, and the second one constrains everything

bx is described in the readme as the Base X-platform library, and the project description calls it a base library used across multiple projects. The goals are stated as two bullets, and the first of them is the usual one: provide OS, runtime and compiler independent core functionality so that cross-platform applications can be written.

The second bullet is the one that defines the project. It compiles without the C Runtime and without the C++ Standard Library, the STL.

That constraint is severe and it explains the shape of everything else. Without the CRT there is no malloc, no printf, no file IO and no time functions, so the library has to provide its own. Without the STL there is no std::string, no std::vector and no std::map, so the containers have to be written from scratch, which is what the tests/ and src/ directories in the tree are for.

The audience follows from that. This is infrastructure for somebody building a larger system, most likely a game engine or a graphics framework, where the same core code has to run on a console, a mobile device and a desktop, and where the platform's C library is either absent, different in behaviour, or a source of binary size you cannot afford. The name bx, and the author Branimir Karadzic, point at that world, and the licence link in the readme badge points at the bgfx project's own licence page rather than at a standalone one.

For an application developer with a compiler and a standard library, none of this is a benefit. It is a constraint you have taken on.

What the repository actually contains

The top-level listing is short, which is unusual for a project that provides core functionality, and it is informative.

There is include/ and src/, which is the expected split for a library with a public API and an implementation behind it. There is tests/, which for a library with hand-written containers and platform abstractions is not an afterthought but the only way to know the code works. There is 3rdparty/, which is where a project like this puts the third-party code it vendors rather than reinvent. And there is tools/ and scripts/, which are the build helpers and the automation around them.

The public API headers live in include/ and the implementation in src/, and the fact that both are top level directories rather than a src/ tree with headers nested inside means the layout is designed to be consumed directly, either as a subdirectory in your build or as a vendored copy.

That last point is worth making explicit, because it is how a project with no package manager, no tags and no releases gets used. The build is a set of scripts in the repository, not an artifact to download, and the .github/ directory holds the continuous integration workflow that keeps it building across the platforms it targets. The .editorconfig and .gitattributes files are the kind of detail that shows up in a repository where many people contribute and the formatting has to be consistent.

The absence of a build directory listing in the tree is the clearest signal of the design. A library that vendors its dependencies and builds from source does not have a binary distribution, so you are compiling it as part of your project. That is a real cost in build time and in maintenance, and it is the price of not depending on anything.

What compiling without a CRT forces you to write yourself

The readme does not itemise the modules, so the specifics have to be inferred from the design goal rather than read off a list. Still, the shape of the problem is well defined.

A C Runtime gives you memory allocation, formatted output, file handling, time and date, environment variables, process control and string handling. A project that compiles without it has to supply those, or to have its users supply them. For an engine, that usually means a custom allocator on top of a platform-specific memory mapping layer, since the alternative is a static heap carved out of a known memory region.

The C++ Standard Library is the larger surface. std::string, std::vector, std::map, std::unordered_map, std::function, smart pointers and the algorithm header are all things a C++ codebase reaches for constantly. A project that avoids all of it needs to provide its own string type, its own dynamic array, its own associative containers, and its own alternatives to std::function, and the tests/ directory is where the correctness of those comes from.

There is a real cost to this, and it is worth naming so the trade is not mistaken for free portability. Hand-written containers are a permanent maintenance burden, and they are usually a subset of the standard ones. A team that writes them once and then debugs them for the life of the project has traded a dependency for a responsibility.

The payoff is equally real. Binary size on a constrained target, the absence of a startup cost, and the ability to run the same code where a CRT does not exist at all, which for a console or an embedded target is not a preference but a requirement.

Where bx is the wrong dependency

The first limitation is that this is a base library, not a framework with an opinionated layer on top. Nothing in the readme describes containers with modern interfaces, error handling conventions, or a logging facility. Adopting it means adopting the pieces you need and writing the conventions yourself, and the amount of work in that depends entirely on how much of the standard library the surrounding project currently leans on.

The second is that there is no release mechanism to depend on. The repository publishes no GitHub releases, there is no version tag to pin in a dependency manifest, and the readme points you at the project page and a Discord chat rather than to a package registry. In practice that means vendoring the source into your tree, which puts the maintenance of that code on you, and there is no upstream version marker that tells you which state you copied. The last push was on 2026-10-20, so the tree does move.

The third is that a base library is only as good as its platform coverage, and the readme does not enumerate platforms or compilers. It promises OS, runtime and compiler independence, which is a statement of intent rather than a compatibility matrix, and a team targeting an unusual platform should establish what actually works before designing around it.

The fourth is the licensing of what it vendors. The 3rdparty/ directory means some of the code you compile is not covered by the BSD-2-Clause terms of the project itself, and each vendored dependency carries its own licence. For a commercial product, that inventory is work, and nothing in the readme does it for you.

The fifth is the scale of the bet. This is infrastructure with no published releases and a single author, and the standard library is the alternative that every compiler vendor already tests. Choosing bx is choosing to own a piece of that, and the reason to do it is the same reason every time: your target cannot have the standard library.

A permissive licence and a single point of contact

The licence is BSD-2-Clause, and the full text is reproduced in the readme itself, which is worth noting because a two-clause BSD is short enough to read in full and short enough that most legal teams have already seen it once.

The terms are the standard ones. Redistribution and use in source and binary forms, with or without modification, are permitted provided two conditions hold. Redistributions of source code must retain the copyright notice, the list of conditions and the disclaimer, and redistributions in binary form must reproduce the same in the documentation or other materials provided with the distribution. The warranty disclaimer and the limitation of liability are the usual ones, and the copyright line reads Copyright 2010-2026 Branimir Karadzic, so the notice has been carried forward across the whole span of the project.

For a base library, that is about as permissive as it gets without going to the public domain, and it is the right licence for this kind of component. The code is meant to be copied into your build, and the two-clause BSD explicitly allows that with only a notice obligation, which is the minimum a commercial product has to carry.

The project page is bkaradzic.github.io, and the readme links a Discord server for chat. There is no issue tracker policy described, no contributing guide and no code of conduct mentioned in the visible text, which for a library that is meant to be vendored is a fair way to organise things: the project is a codebase with a licence and a conversation channel, and everything else is left to the person integrating it.

The project description mentions that bx is used across multiple projects, and the licence badge in the readme links to the bgfx licence page, so the pattern is one author maintaining a shared base that several of their own larger projects consume.

Editorial conclusion

bx fits a systems programmer writing an engine or a tool for a target that has no usable standard library, since the whole point of the project is that its core functionality does not depend on the CRT, the STL, the operating system or the compiler, and the BSD-2-Clause licence makes it easy to vendor. It is the wrong choice for an application that already links a standard library, because you would be replacing a well-tested implementation with a small one for no benefit. Before adopting it, read the goals in the readme against your own target, and note that the repository publishes no GitHub releases, so there is no version to pin, with the last push on 2026-10-20 and the project page at bkaradzic.github.io.

Frequently asked questions

Official sources

1. bkaradzic/bx on GitHub
2. Issues
3. License: BSD-2-Clause
4. Project website
5. README