tbox: the glib-like C library that fits in 64K

The glib comparison, and the four build sizes

tbox describes itself as a glib-like cross-platform C library that is simple to use yet powerful in nature, and the stated focus is making C development easier through many modules, stream, coroutine, regex, container, algorithm, so that any developer can pick it up and feel the productivity difference. The more telling self-description is in the build options, four compiling profiles offered through xmake, Release stripped of debug information and optimized, Debug with assertion and memory checking enabled, Small with all extensional modules disabled and space optimization on, and Micro, a compiled library of roughly 64K for embedded systems. A library that can present itself as either a full development foundation or a 64K embedded kernel is making a claim about discipline that feature lists cannot, and the platform list, Windows, macOS, Linux, Android, iOS and the BSDs, matches the embedded ambition rather than the desktop one.

Coroutines with both stacks and every poller

The coroutine library is the deepest module. It provides high-performance coroutine switching with architecture-specific implementations for arm, arm64, x86 and x86_64, channel and semaphore and lock interfaces in the style popularized by Go, and io socket and stream operations that run inside coroutines, including small io servers such as http built on them. Both stackfull and stackless coroutines are supported, the two implementation philosophies usually forced into separate libraries, and the event backends span epoll, kqueue, poll, select and IOCP, covering Linux, the BSDs and macOS, and Windows respectively in one abstraction. The ability to wait on a pipe, a socket and a process in coroutine and poller at the same time is the kind of detail that separates a coroutine library designed for real programs from one designed for benchmarks, and the platform library's switch-context interfaces exist specifically to back this layer.

Streams, filters and the async seam

The stream library sits above raw IO as the library's unified data layer, supporting file, data, http and socket sources with filters for gzip and charset conversion, stream transfer between sources, and static buffer streams for parsing data in place. The design seam with coroutines is explicit, streams support coroutine and implement asynchronous operation, so the same read and write calls run blocking-style in a coroutine or synchronous in plain code. The network library beneath provides cached DNS, http with cookies, IPv4 and IPv6, and SSL through openssl, polarssl or mbedtls, three interchangeable TLS backends, an unusually generous set that lets a project match whatever its platform already ships. For data formats, the serialization library covers xml, json, bplist, xplist and binary, the xml parser offers DOM and SAX modes with xpath, and the charset library converts between utf8, utf16, gbk, gb2312, uc2 and uc4 with both endianness modes, the East Asian encodings marking the library's origin.

A memory checker in debug mode

The memory library is two things at once, a set of memory pools for optimizing allocation, and in debug mode a fast memory error detector that catches out-of-bounds accesses to heap and globals, use-after-free, double-free and invalid free, and memory leaks. Embedding sanitizer-class detection in the library itself means every build in Debug configuration carries it without wiring an external toolchain, and combined with the assert and trace output in the utils library, the debug profile becomes a self-diagnosing runtime rather than just an unoptimized one. The libc module reinforces the same care, lightweight libc interfaces with a tb_ prefix to avoid symbol conflicts, optimized versions of frequently-used functions like memset and memcpy, and typed extensions such as memset_u16, memset_u32 and memset_u64 for the cases the standard interface handles awkwardly, plus a libm companion supporting float and double.

Containers, algorithms and the iterator contract

The container library implements hash tables, single and double lists, vectors, stacks, queues and min and max heaps, and the algorithm library operates on all of them through the iterator mode, find, binary find and reverse find, five sorts including quick, heap and insertion, and traversal operations from count through for_all and rfor_all. This is the classic container-algorithm separation the C++ standard library made canonical, delivered in plain C, and its value is the one the design promises, any container works with any algorithm because both speak the iterator contract. Supporting modules round out the toolkit, a math library with random generation and fixed-point calculation at 6-bit, 16-bit and 30-bit precision for platforms without floating point, a hash library with crc32, adler32, md5 and sha1 plus a dozen string hashes and a uuid generator, base32 and base64 codecs, and a regex library supporting match and replace with global, multiline and caseless modes over pcre, pcre2 or posix backends.

Built by the xmake author, and used by xmake

The build story is unusually tight. tbox builds through xmake, and the list of projects using tbox includes xmake itself, the build tool's own website listed among the dependents, a bootstrapping relationship where the library and the build system reinforce each other's quality. The documented builds cover the host platform in two commands, cross compilation to mingw with an sdk path, to iphoneos, to android with an NDK path, and to linux with a generic sdk, each the same configure-and-build pair:

# build for the host platform
$ cd ./tbox
$ xmake

An alternative xmake.sh path exists for environments without xmake:

$ ./configure
$ make

Other dependents include gbox, the same author's graphics library, vm86, and itrace, a family of tools sharing the foundation, and the example program in the README opens with tb_init and closes with tb_exit, the init and cleanup pair every tbox application begins from.

A bilingual project in steady motion

The project carries both an English and a Chinese README, documentation hosted at docs.tboox.top with a getting-started trail, and community channels spanning Reddit, Gitter, Telegram and a QQ group, the full bilingual apparatus of a Chinese-origin project serving an international audience, with an Open Collective page and a donation route for sponsorship. Release cadence is healthy and current, v1.8.0 in February 2026, v1.8.1 in July and v1.8.2 in August, with the repository pushed on 2026-09-15, and a CHANGELOG tracks the line. The contribution and conduct documents are in place, and the source tree is formatted under clang-format. Measured against its genre, tbox is the rare glib-alike that stayed coherent, fifteen libraries sharing one naming convention, one iterator contract and one build system, maintained by an author who also maintains the build tool that compiles it.

Editorial conclusion

Use tbox when a C project needs a portable foundation, streams, coroutines, containers, sockets, XML, hashing, without pulling glib's size or its ecosystem assumptions, especially on embedded or mobile targets where the Micro configuration's footprint matters. Use glib when you are already inside the GNOME stack and its conventions, or the C standard library plus a few focused libraries when the need is one module rather than fifteen. Verify first which optional backends your build resolves, since regex, SSL and zlib features ride on pcre, mbedtls and zlib being present, and read the documents at docs.tboox.top for module-level guidance before committing to its interfaces.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tboox/tbox on GitHub