libxutils - Cross-platform C library release 2.x

libxutils is a low-level cross-platform C library designed to eliminate the need for stitching together dozens of unrelated libraries.

It provides a unified, event-driven runtime with consistent APIs for networking, data structures, cryptography and system utilities, optimized for performance-critical native applications.

The library targets Linux, Unix and Windows and is released under the MIT license.

What makes it strong

• One consistent low-level stack instead of multiple libraries
• Explicit memory and ownership model
• Event-driven architecture
• Minimal dependencies with optional OpenSSL
• Designed for high-performance native software where control and predictability matter

Core strength: networking

The strongest side of libxutils is networking.

Instead of combining separate libraries for sockets, event loops, HTTP, WebSocket, SSL and protocol glue, libxutils keeps them inside one library with shared conventions for buffers, callbacks, ownership and runtime flow.

Built-in networking pieces include:

• Raw sockets, Unix sockets, TCP and UDP
• SSL (optional)
• HTTP
• WebSocket
• MDTP
• Cross-platform event loop integration

HTTP, WebSocket and raw TCP share the same callback model, endpoint setup and event loop. Switch between protocols by changing a single enum — the rest of your code stays the same. More importantly, they can coexist: a single instance can serve an HTTP API on one port, a WebSocket feed on another and a raw TCP control channel on a third, all multiplexed through one service loop with no threading required.

Typical use cases

• High-performance network services such as HTTP and WebSocket servers, gateways and proxies
• CLI tools that need networking, JSON, crypto and filesystem support in one binary
• Embedded or system-level software with minimal dependency requirements
• Custom runtimes and protocol implementations
• Native backends exposed to higher-level languages through FFI

Why libxutils?

libxutils started as a personal utility library in 2015 and has evolved over years of real-world use into a focused, production-tested stack.

The library is designed around predictable performance and explicit resource control. There are no hidden allocations, no implicit threading and no garbage-collected layers — memory ownership is always visible at the call site.

Every commit is tested against Valgrind as part of the CI pipeline to catch leaks, invalid reads and use-after-free errors before they reach a release. Combined with CodeQL static analysis running on every push, the codebase is continuously checked for memory safety and overall quality.

The result is a library that stays small, builds fast and behaves the same way whether it runs in a long-lived server or a short-lived CLI tool.

Compared to other stacks

Feature	libxutils	libuv	boost::asio	curl + ad-hoc stack
Integrated full stack	✔️	❌	❌	❌
Event loop	✔️	✔️	✔️	❌
Built-in HTTP/WebSocket	✔️	❌	❌	❌
Built-in crypto helpers	✔️	❌	❌	❌
Minimal external deps	✔️	✔️	❌	❌
Ecosystem maturity	Medium	High	High	High
Community / adoption	Growing	Very high	Very high	Very high
High-level abstractions	Selective	Limited	Moderate	Varies
Learning curve	Moderate	Moderate	Higher	Varies

This comparison reflects what each library provides out of the box, without requiring additional libraries or integrations.

Documentation

Full documentation is available in the docs directory.

• Start with docs/README.md for the full index
• Category indexes are available in networking, data, crypto and system
• The docs/ tree documents the real behavior from src/, including arguments, return values, callback contracts and known quirks

Library modules

Each module below links to documentation with API contracts and behavior.

Networking

• High-level event-driven API for HTTP, WebSocket, MDTP and raw sockets
• Cross-platform socket layer
• Cross-platform event loop
• HTTP parser/client helpers
• WebSocket framing
• MDTP packet protocol
• RTP packet helpers
• Address/interface helpers

Data and containers

• Dynamic array
• Byte/data buffers
• Key/value map
• Hash map
• Linked list
• C string utilities and dynamic string
• JSON parser/writer/formatter
• JWT parser/writer/verifier

Cryptography and encoding

• Cryptography dispatch helpers
• AES encryption and decryption
• Base64 and Base64Url
• RSA helpers
• SHA-256
• SHA-1
• CRC32
• HMAC
• MD5

System and runtime

• File and directory operations
• CPU affinity helpers
• Recursive file/content search
• Time and date helpers
• Resource monitoring
• Memory pool
• File and screen logging
• Synchronization primitives
• Threading and repeating tasks

Miscellaneous

• CLI helpers and progress bars
• Signal and daemon helpers
• Small type/format helpers
• NTP client helpers
• Version helpers

Quick example

Minimal event-driven HTTP server example. For a more complete implementation with logging, timeouts, SSL and full connection lifecycle handling, see examples/http-server.c.

This example shows the core event-driven flow:

• Accept a connection
• Read HTTP request
• Assemble a response
• Send it back
• Close the session

#include <xutils/api.h>

static int on_request(xapi_session_t *s)
{
    xhttp_t *req = (xhttp_t*)s->pPacket;
    (void)req; // handle request here

    xhttp_t res;
    XHTTP_InitResponse(&res, 200, NULL);
    XHTTP_AddHeader(&res, "Content-Type", "text/plain");

    const char *body = "Hello from libxutils\n";
    XHTTP_Assemble(&res, (const uint8_t*)body, strlen(body));

    XAPI_PutTxBuff(s, &res.rawData);
    XHTTP_Clear(&res);

    return XAPI_EnableEvent(s, XPOLLOUT);
}

static int callback(xapi_ctx_t *ctx, xapi_session_t *s)
{
    switch (ctx->eCbType)
    {
        case XAPI_CB_ACCEPTED:
            return XAPI_SetEvents(s, XPOLLIN);

        case XAPI_CB_READ:
            return on_request(s);

        case XAPI_CB_COMPLETE:
            return XAPI_DISCONNECT;

        default:
            return XAPI_CONTINUE;
    }
}

int main(void)
{
    xapi_t api;
    XAPI_Init(&api, callback, NULL);

    xapi_endpoint_t ep;
    XAPI_InitEndpoint(&ep);

    ep.pAddr = "0.0.0.0";
    ep.nPort = 8080;
    ep.eType = XAPI_HTTP;
    ep.eRole = XAPI_SERVER;
    XAPI_AddEndpoint(&api, &ep);

    while (XAPI_Service(&api, 100) == XEVENTS_SUCCESS);

    XAPI_Destroy(&api);
    return 0;
}

A single abstraction covers HTTP, WebSocket and raw TCP. The same XAPI_Init → XAPI_AddEndpoint → XAPI_Service flow, the same callback signature and the same return codes apply regardless of protocol. Code written for one transport carries over to another with minimal changes, which removes the integration cost of combining separate libraries for each protocol. Multiple endpoints with different protocols can also run side by side in the same event loop, making it straightforward to expose an HTTP API, a WebSocket stream and a raw TCP channel from one process without threads or external glue.

Installation

There are several ways to build and install the library.

Using the included script

This is the simplest path on Linux and macOS:

git clone https://github.com/kala13x/libxutils
./libxutils/build.sh --install

Supported build-script options:

• --tool=<tool> choose cmake, smake or the included make
• --install install the library and tools after building
• --examples include examples in the build
• --tools include tools in the build
• --clean remove object files after build/install

If --tool is omitted, the script uses cmake by default.

Using CMake

git clone https://github.com/kala13x/libxutils
cd libxutils
cmake . && make
sudo make install

Using SMake

SMake is a simple Makefile generator for Linux/Unix:

git clone https://github.com/kala13x/libxutils
cd libxutils
smake && make
sudo make install

Using the included Makefile

The project can also be built with the pre-generated Makefile on Linux:

export XUTILS_USE_SSL=y # Enable SSL-related features
git clone https://github.com/kala13x/libxutils
cd libxutils
make
sudo make install

Dependencies

OpenSSL is the only external dependency and is only required for SSL and RSA functionality. If the development package is missing, the library can still be built without SSL support.

Install OpenSSL development package

Red Hat family: sudo dnf install openssl-devel
Debian family: sudo apt-get install libssl-dev
Windows: choco install openssl
macOS: brew install openssl

Usage

Include the required <xutils/*.h> headers in your project and link with -lxutils.

For exact runtime behavior, use the documentation in docs/ instead of relying on symbol names alone.

Examples and tools

The project contains two useful reference areas:

• examples/ contains smaller and simpler examples focused on showing how to use specific parts of the library
• tools/ contains larger, more advanced examples in the form of ready-made CLI applications built on top of the library

You can build both with:

./libxutils/build.sh --tools --examples

You can also build examples manually:

export XUTILS_USE_SSL=y # Enable SSL-related features
cd examples
cmake .
make

XTOP and included tools

XTOP is an HTOP-style performance monitor that displays CPU, memory and network activity in a single CLI window and has a powerful REST API client/server (daemon) mode and much more. It is also a good example of how much can be built on top of the library without adding a large external stack.

After building the sources in tools/, run sudo make install to install:

• xcrypt - file and text encrypt/decrypt CLI tool
• xpass - secure password manager CLI tool
• xjson - JSON linter and minifier CLI tool
• xhttp - HTTP client CLI tool
• xhost - hosts-file search and modification CLI tool
• xtop - resource monitor CLI tool
• xsrc - advanced file search CLI tool

Run each tool with -h to see usage and version information.