KyriaiOS — Public Beta 2 (Build 16)

Kernel internals — what changed and why it matters

The Beta 2 kernel is intentionally compact, readable, and designed for experimentation. The code base includes a set of freestanding helpers (string and memory primitives), an interactive VGA text terminal, port I/O wrappers, and a concise main loop that drives the command shell and cooperative scheduler.

Memory allocator (kmalloc/kfree): The kernel implements a simple free-list allocator placed at a fixed heap region (the implementation uses a contiguous heap area and a linked list of free blocks). Allocation is first-fit: the allocator rounds requested sizes to a 4-byte alignment, reserves header space for bookkeeping, and either splits blocks when a large block is available or takes the whole block. Freed blocks are inserted back into the free list in address order, and adjacent free blocks are coalesced to reduce fragmentation. This approach is small, deterministic, and sufficient for the in-memory workloads the kernel targets. It is important to note that this allocator is not SMP/interrupt-safe — it is designed for a single-threaded kernel or cooperative task model.

Why this matters: moving from raw assembly to a clear C allocator reduces memory bugs, makes it straightforward to track leaks (file deletion now frees the data and the file struct), and enables future improvements (alignment, locking) without rewriting the whole kernel.

Cooperative tasks and scheduler

Rather than implementing full preemptive context switching (which requires careful assembly code for stack and register management), Beta 2 offers a simple cooperative task model. Tasks are represented by a small C struct holding a callback and an argument pointer. The scheduler iterates over the registered tasks and calls each callback in turn. Tasks must be short and cooperative — they return quickly so the system can respond to user input. The kernel provides functions to create and remove tasks (returning a TID for management), and the shell exposes commands to list and kill tasks.

Kernel panic

For fatal errors the kernel provides a clear, immediate failure mode: a BSOD-style kernel_panic that switches the VGA terminal to a blue background with white text, prints a message, then halts the CPU. This deterministic behavior is useful during development: crashes are obvious, and the panic message gives immediate feedback on what went wrong.

VGA terminal and BMP rendering

The terminal driver handles scrolling, color attributes, and basic character drawing to the VGA buffer. A terminal image feature converts embedded 24-bit BMP data into an 80×25 terminal background by averaging pixel brightness per terminal cell and mapping the result into the 16 VGA color palette. Embedded bitmaps are linked into the kernel (via object copy/linker symbols) and can be selected from the shell; this allows a text-mode "wallpaper" effect without a graphics driver.

RTC, uptime, and system info

The kernel reads the CMOS RTC at boot (handling BCD conversion and 12/24-hour modes) to establish a boot timestamp. The shell exposes an uptime command that computes elapsed time using the RTC values. If RTC reads fail or are uninitialized, the kernel reports uptime as unknown — a clear signal for the tester.

File system — how the in-memory layout works

Beta 2 provides a simple, robust in-memory filesystem intended for testing shell features and safe experimentation. The structure is intentionally small and well-documented so contributors can evolve it into on-disk persistence later.

The filesystem uses two primary structures: Directory and File. Directories hold a fixed array of child directory pointers (up to a small limit) and a pointer to a linked list of files. Files are allocated via the kernel allocator; each file record contains a fixed-length name buffer, a pointer to content (a separate allocation, length stored), and a next pointer for the linked list.

Behavior highlights:

• Creation: touch and txtedit allocate file structures and, if content exists, a content buffer via kmalloc.
• Reading: cat prints file content directly to the terminal buffer (content is NUL-terminated when created by the editor).
• Copy/Move: cp duplicates file data into a new allocation; mv renames the file in place.
• Deletion: rm unlinks the file and frees both the content buffer and the file struct using kfree, returning memory to the allocator.
• Install simulation: the install command copies an in-memory file to a simulated /system directory, demonstrating the flow that future disk-writes will follow; currently it remains in RAM and is not persistent across reboots.

Important limitation: This filesystem is currently in-memory only. While a FAT32 skeleton and API placeholders are included in the kernel (data structures for BPB fields, stubbed mount/read/write functions), full on-disk FAT32 support requires a block device driver, BPB parsing, FAT chain traversal, and robust directory entry handling — these are listed as TODOs in the kernel and are intentionally left for a future release once a disk driver is available.

What to expect when using Beta 2

Beta 2 is an early public release intended for testers and contributors, not general production use. Expect a responsive text-mode shell, a reliable in-memory filesystem, and clear, reproducible behavior. You will notice the following practical realities as you use it:

Boot and testing: The recommended workflow is to place the kernel image in a GRUB ISO or USB layout and boot from removable media. GRUB will load kernel.elf into protected mode, initialize the terminal and heap, and present a prompt that looks like C:>root:KyriaiOS~$. Booting from USB ensures your primary system remains unchanged and lets you iterate fast.

Commands and shell behavior: The shell parses arguments by tokenizing on spaces and dispatches a broad command set implemented in C. Commands include file operations (touch, rm, cp), utilities (txtedit, calc), system tools (sysinfo, uptime), and management stubs (sfc, chkdsk, netsh). Note that commands in the current kernel are implemented in conventional lower-case tokens (i.e. not the old single-CAPS requirement from Beta 1).

Persistence and limits: Because the current filesystem is RAM-backed, files you create will not survive a reboot unless you use a future persistent backend (FAT32 or block device support). The install command simulates installation to /system by copying into a memory directory — useful for testing installation flows but not a substitute for actual disk writes yet.

Graphics and backgrounds: The kernel supports embedding 24-bit BMP data into the binary. When you run the chbg command and select an embedded image (e.g., img1), the kernel transforms that bitmap into an 80×25 terminal background by averaging brightness and mapping to VGA colors. This is a text-mode approximation (not a framebuffer driver) and is ideal for low-RAM artistic presentations.

Multitasking model: The scheduler is cooperative: tasks register simple callbacks that the kernel calls periodically between command dispatches. Tasks must yield quickly; they are not preempted. This makes debugging simple and avoids the complexity of context switches while still demonstrating multi-activity capability (timers, background jobs, simulated services).

Safety and failure modes: The kernel includes a robust kernel_panic that sets a blue background, prints a panic message, then halts. This behavior gives immediate, unambiguous feedback for developer mistakes or unexpected conditions. Use the panic output to reproduce issues and attach logs when filing bugs.

Download & safety guidance

We strongly recommend testing KyriaiOS Beta 2 by booting from a live USB. The distribution is packaged for GRUB, allowing you to boot the kernel without writing to local disks. Live testing is the safest way to evaluate the OS functionality, exercise the filesystem, and validate features such as txtedit, chbg, and sysinfo without risking user data.

Installing to physical hardware is possible but not recommended for general users. While Beta 2 is a major step forward from the assembly prototype, it still lacks a full, production-grade block device driver and on-disk filesystem. Installing to a real partition could overwrite existing data. If you choose to install, please back up your drive and perform the install on a spare disk or virtual machine.

Safety checklist before testing on real hardware:

• Create a full backup or system image of any drive you might overwrite.
• Test in a VM (QEMU/VirtualBox) before booting a physical machine.
• Prefer USB live boot via GRUB for interactive exploration.
• Do not rely on Beta 2 for persistent storage — it is RAM-backed unless you implement the disk driver and FAT32 handling.

Changelog / What makes this update so important"

Beta 2 is a structural rework rather than a small patch. The most important differences compared to Beta 1 are:

• Implementation language and mode: Beta 1 was a 16-bit real mode assembly prototype; Beta 2 is a C implementation running in 32-bit protected mode — this change alone shifts the focus from a demonstration to a maintainable kernel capable of adding services and drivers.
• Memory safety and allocator: The kernel introduces a kmalloc/kfree free-list allocator with splitting and coalescing. Beta 1 had no heap or safe dynamic allocation model.
• Real filesystem semantics: Beta 2 implements directories, files, copying, renaming, and deletion with memory reclamation — a big step beyond the single-command demo in Beta 1.
• Workable shell and tooling: More than thirty commands and utilities (editor, calc, system tools) are available for meaningful interaction and test coverage.
• Foundations for devices: FAT32 structures and block-device stubs are present, documenting how on-disk persistence will be added without touching the rest of the system architecture.

Because Beta 2 touches core architecture (mode, memory, filesystem), it is a platform shift — upgrades from Beta 1 are not simply backwards compatible patches. Instead, Beta 2 is the new baseline for future feature development and stability improvements.

Feedback, reporting, and contributing

Beta releases benefit enormously from high quality bug reports and reproducible test cases. If you find an issue, please include:

• Steps to reproduce (exact command sequence)
• What you expected to happen
• What actually happened (console output, panic text if any)
• Hardware/VM details (model, BIOS/UEFI settings, VM configuration)

Send reports or patches to kyriaisoftware@gmail.com. Feedback is welcome — Current Bugs found can be found on: Bug Report site! - Archives