Introduction

Helctic is a multi-OS syscall personality kernel. The goal: run an unmodified binary built for Linux, Windows (NT), Darwin (macOS), or the BSDs directly on top of a native Rust microkernel, with no recompilation and no userspace virtual machine.

It does this the way FreeBSD's Linuxulator or Windows' WSL1 does — by translating foreign syscalls in the kernel — but generalises the idea to many operating systems behind a single, pluggable abstraction called a personality.

The core idea

Every process carries a personality that says which OS ABI it expects. When the process traps into the kernel with a syscall, the personality determines:

1. Which syscall-number table to dispatch through.
2. How arguments and structures are translated to the kernel's internal form.
3. How return values and errors are encoded for that OS.
4. Signal numbers and delivery semantics.
5. Process startup convention (registers, stack, aux vectors).

The personality is detected from the binary itself during exec() — from the ELF OS/ABI byte, the PE machine type, or the Mach-O cputype.

Two languages, one kernel

• The kernel core is Rust — memory management, the scheme (VFS) layer, contexts/scheduling, and the trap handlers.
• The personality layer is Zig — compiled to a static library and linked into the kernel, talking to the core through a flat C-ABI kernel-ops callback table.

See Architecture for the full picture.

Project status

Helctic is early. Here is the honest state of things:

Area	Status
Personality architecture & FFI boundary	Wired
Build toolchain (Rust nightly + Zig + CI)	Modern, building infra in place
Personality detection helpers (ELF/PE/Mach-O)	Implemented (Zig)
Kernel-ops table installed at boot	Yes (init_personality() in kmain)
Linux syscall table	~80 of ~450 mapped
Kernel-ops callbacks wired to real ops	write, exit, and pid/uid/gid getters
ELF → personality wiring during exec	Not yet wired (defaults to native)
Windows / Darwin / BSD personalities	Not started

Known limitations

• ELF personality detection is implemented in the Zig helper but not yet called from the Rust exec() path; contexts default to the native personality.
• Most kernel-ops callbacks still return ENOSYS.
• mmap, brk, and arch_prctl are required before a static Linux binary can run, and are not yet wired.
• The kernel currently has known compile gaps from an in-progress syscall_handler refactor (the scheme layer expects the full legacy syscall API). Completing that migration is tracked separately.

Roadmap

Milestone	Goal
M1 — Hello World	A static Linux binary runs (ops table + core syscalls)
M2 — Busybox	A shell with basic commands (path translation, extended syscalls)
M3 — Dynamic apps	Python, gcc, etc. (full syscall table, signals, ld-linux)
M4 — Multi-OS	Windows + Darwin basic support
M5 — Production	Performance parity (vDSO, compat layers, benchmarks)

Lineage

The microkernel core derives from the Redox model (scheme-based VFS, rmm memory management, custom x86_64-unknown-kernel target). Helctic adds the multi-personality syscall architecture on top.