Skip to content

adriantips/boltossource

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

BoltOS

A 64-bit operating system written from scratch in C and x86-64 assembly — no GRUB, no Multiboot, no external libraries. Custom boot chain (legacy BIOS MBR + UEFI), own kernel.

Status: active development. Custom boot chain (stage1 → stage2 → long mode, or UEFI → long mode) into a 64-bit C kernel. UEFI boot, ACPI, APIC, SMP (symmetric multiprocessing), HPET, a framebuffer compositor and windowed GUI desktop with 24 apps (including a playable port of DOOM), a preemptive round-robin scheduler with processes and ring-3 userland (ELF64 loader + syscalls), physical and virtual memory management (including ASLR, SMAP, SMEP and swap), a persistent filesystem on real ATA / NVMe / AHCI SATA disks (HDD/SSD) behind a VFS and generic block layer, EXT2 and FAT32 standard filesystem support, hardware interrupts, keyboard and mouse drivers, an xHCI USB host-controller driver with HID support, an AC97 audio driver, an interactive shell, a full IPv4/TCP/UDP/TLS 1.2+1.3 network stack (with X.509 certificate verification and DHCP) on an e1000 NIC, a standards-ish web browser with a real DOM tree, CSS cascade, box/flex/grid layout engine and a from-scratch JavaScript interpreter, a multi-language IDE with from-scratch C / C++ / C# compilers and a Python interpreter, a GPU / display-adapter driver, support for running real Windows PE32+ executables, PC-speaker + AC97 audio, TrueType font rendering, a system-wide clipboard, stack canary protection, multi-user support, a package manager, a full freestanding libc, and image decoding.

Image Preview

BoltOS Desktop

A screenshot of the BoltOS desktop showing the windowed GUI, taskbar, and desktop launcher icons.

Desktop & apps

The GUI (kernel/gui.c) is a compositing window manager: every window draws into a backbuffer through vector helpers (g_fill, g_round, g_text, gui_icon, …), which is flipped to the framebuffer. Windows support move/resize, focus/z-order, minimize/maximize, a taskbar with pinning, right-click context menus, and a desktop of double-clickable launcher icons. Font rendering uses TrueType outlines (kernel/ttf.c) in addition to the built-in bitmap fonts. A system-wide clipboard (kernel/clipboard.c) enables copy/paste across apps. Each app is a kernel/app_*.c file exposing draw/key/click/drag/tick callbacks.

Bundled apps (24):

  • Terminal — the full interactive shell in a window
  • File Explorer — browse/open the persistent filesystem
  • Browser — a layout-engine web browser (DOM + CSS cascade + box/flex/grid + JavaScript) over the kernel's own HTTP/HTTPS stack
  • OldBrowser — a NetSurf port: the NetSurf core architecture (nsurl, content cache, handler pipeline, browser_window + back/forward history) with its classic framebuffer-frontend toolbar (Back / Forward / Reload / Stop / Home, address bar, throbber, bookmarks), rendering through the BoltOS layout engine over the kernel TCP/TLS stack
  • Code — a multi-language IDE (C / C++ / C# / Python) with syntax highlighting, line numbers, a Run button and an output console
  • Task Manager — live process / CPU / memory view
  • Settings — themes and system options (persisted), font switching
  • Calculator, Clock, Stopwatch, Calendar, Notes (saved to FS)
  • Paint, Color Picker, Piano (PC-speaker, zoomable multi-octave)
  • System Info, Matrix rain
  • Games: DOOM (real doomgeneric port, playable E1M1), Minesweeper, Snake, 2048, Tic-Tac-Toe, Memory match, Conway's Game of Life

The kernel logic is fixed-point / integer math, but SSE is enabled and the FPU/SSE register file is saved and restored across context switches: the scheduler gives every thread its own 512-byte FXSAVE area and the ISR common path (kernel/isr.asm) fxsaves the outgoing thread and fxrstors the incoming one around every interrupt, so XMM/x87 state never leaks between threads. Ring-3 programs (e.g. the libc libm) can use floating point freely.

Userland (ring 3, ELF64)

BoltOS runs real user programs in ring 3. user/ is a tiny freestanding C program (crt0.asm + ulibc.c) linked to a static ELF64 (user/user.ld) and embedded into the kernel image at build time. The kernel's ELF loader (kernel/elf.c) maps the segments into a fresh address space; the program traps into the kernel via syscall (kernel/syscall.asm + syscall.c) for I/O. A preemptive round-robin scheduler (kernel/sched.c) with per-process state (kernel/proc.c) time-slices processes off the PIT. Userland benefits from ASLR (randomised load base), SMAP/SMEP (kernel/user page isolation), and per-process address spaces.

Ring-3 browser & JS

The web browser, DOM/layout engine and JavaScript interpreter run in ring 3, not in the kernel. kernel/{dom,layout,js}.c — the HTML tokeniser + DOM tree builder, the CSS cascade + box/flex/grid layout engine, and the BoltJS interpreter — are the same sources the kernel uses, but they are also compiled into two userland ELF programs and executed in ring 3:

  • /bin/js (user/js_main.c) — the JavaScript interpreter as a ring-3 program. js FILE.js execs it; the language runtime never touches kernel mode.
  • /bin/browser (user/browser_main.c) — the web browser as a ring-3 program. It loads a page (local file, or a URL through the kernel network stack), builds the DOM, runs the CSS cascade + layout, executes the page's JavaScript (with a real DOM-bound js_host, including fetch()), and paints the box tree to the framebuffer — all in ring 3. Launch it with the webx [url] shell command; keys scroll / follow links (Tab+Enter) / edit the address bar (g) / quit (q).

The kernel exposes only the privileged primitives behind four syscalls (include/syscall.h): SYS_FBINFO maps the framebuffer into the process and pauses the compositor (a g_fb_exclusive flag the GUI loop checks), SYS_GETKEY reads the keyboard, SYS_HTTPGET fetches a URL over the in-kernel TCP/TLS stack, and SYS_FBEND hands the screen back. No HTML parsing, layout, or script execution happens in ring 0. (The in-window desktop Browser app still uses the in-kernel copy of the engine for its embedded window.)

ACPI / APIC / SMP

ACPI (kernel/acpi.c) discovers the RSDP, RSDT/XSDT, and MADT, and provides table-checksum validation — the foundation for APIC, HPET, and SMP boot.

APIC (kernel/apic.c) reprograms the local APIC and I/O APIC, replacing the legacy PIC for interrupt routing. Each CPU core gets its own local APIC timer.

SMP (kernel/smp.c + kernel/ap_boot.asm + kernel/hpet.c) brings up application processors: the BSP writes the trampoline to low memory, sends an IPI, and each AP runs its own idle loop. The HPET provides a cross-core synchronised time base. The CPU count is reported in sysinfo.

UEFI boot

boot/uefi_boot.c is a UEFI boot loader (BOOTX64.EFI) that boots BoltOS on modern firmware with no CSM/legacy BIOS. It reproduces the environment the kernel expects from the legacy stage2: loads the kernel at 0x100000, sets up long-mode page tables (identity + higher-half direct map), and passes a bootinfo struct (GOP framebuffer + memory map) in RDI. Built with clang --target=x86_64-unknown-windows (MS ABI) and linked as an EFI application.

Storage (HDD / SSD / NVMe / AHCI SATA) + VFS

Storage sits behind a generic block layer (kernel/blk.c + include/blk.h): a small registry of blkdev_t transports plus shared MBR-partition helpers, so the filesystem doesn't care whether a disk is ATA, AHCI, or NVMe.

An ATA/IDE PIO block driver (drivers/ata.c) probes the legacy ATA register file on both channels (ports 0x1F0/0x3F6 and 0x170/0x376), runs IDENTIFY on each slot, and supports LBA28/LBA48 sector read/write. The same command set drives both spinning HDDs and SSDs; the two are told apart from IDENTIFY word 217 (nominal media rotation rate: 1 = non-rotating = SSD). ATAPI/CD-ROM slots are detected and skipped.

An NVMe driver (drivers/nvme.c) brings up a controller over PCI/MMIO: it sets up the admin queue pair, runs IDENTIFY, creates one I/O queue pair, and registers namespace 1 with the block layer. Completions arrive on a hardware MSI/MSI-X interrupt (pci_msi_enable routes a vector to the local APIC, the I/O completion queue is created with IEN=1): the issuing thread hlts until the interrupt wakes it instead of busy-polling the CQ phase bit. If the controller exposes no MSI capability the driver falls back to polling so it still works everywhere.

An AHCI (SATA) driver (drivers/ahci.c) drives Serial ATA host bus adapters over DMA. Each port gets a command list, received FIS area, and command table; one command runs at a time out of slot 0. Polled completions keep the code synchronous.

The native filesystem (BoltFS, fs/ramfs.c) is reached through a VFS layer (kernel/vfs.c). It is no longer RAM-only: fs_persist_init() attaches the first non-boot disk (preferring NVMe, then SSD, then HDD), loads a saved image on boot (or formats the seed tree if none), and autosaves the whole tree on every mutation, so files survive reboots. The on-disk format is a superblock plus a serialised pre-order node list. diskinfo lists detected disks + media type; sync forces a flush. QEMU exposes data disks (run.sh) across both transports.

Standard filesystems (EXT2 / FAT32)

Beyond BoltFS, the kernel can mount EXT2 (fs/ext2.c) and FAT32 (fs/fat32.c) volumes — read/write for FAT32, read-only for EXT2. Both go through the generic block layer and VFS, so standard disk images from Linux or Windows are accessible from the shell and File Explorer.

Audio (AC97)

An AC97 audio driver (drivers/ac97.c) drives the Intel ICH AC97 controller over PCI. It programs the PCM out channel (stereo 16-bit, 48 kHz), sets up a DMA buffer via the bus-mastering engine, and exposes a simple audio_play(buf, len) interface. Audio coexists with the legacy PC speaker (drivers/pcspk.c).

Web browser & network stack

The windowed Browser is no longer an HTML flattener — it is a small but real rendering engine. A page is parsed into a DOM tree (kernel/dom.c): a proper tokenizer + tree builder with implicit-close rules, void/self-close/raw-text handling, and a selector engine (type/.class/#id/universal, compound selectors, descendant and child combinators, selector lists) backing querySelector / querySelectorAll plus DOM mutations.

On top of the tree sits a CSS cascade + layout engine (kernel/layout.c):

  • Cascade#hex / rgb() / rgba() / hsl() / hsla() / named / transparent colors, selector specificity (a,b,c) + source order, property inheritance, intrinsic tag defaults, and inline style="".
  • Layout — the box model (margin / padding / border / width → border-box), block + inline flow with text word-wrap on the bitmap-font grid, flexbox (row/column, flex-grow, gap, justify-content, align-items) and CSS grid (px + fr tracks, repeat(), gaps, row wrapping).

This box tree is what the Browser actually paints — backgrounds, borders, wrapped text, images, inputs and hit-tested links — relaid out on width change (responsive). The NetSurf libcss library (vendor/libcss-0.9.2/) and libhubbub HTML parser (netsurf/libhubbub/) are also compiled in, supporting the OldBrowser port and the nstest validation command.

A from-scratch JavaScript interpreter (kernel/js.c, "BoltJS") runs page scripts: lexer → recursive-descent (precedence-climbing) parser → AST walker. Numbers are int64 (no FPU). It is wired to the real DOM: document.querySelector, createElement, appendChild, setAttribute / getAttribute, element id / className / href / value, document.cookie, and localStorage / sessionStorage; mutations trigger reflow. A persistent VM lives for the page's lifetime, so it also has an event loop: addEventListener with click dispatch, setTimeout / setInterval / requestAnimationFrame (driven off the PIT tick), and fetch() returning real Promises (.then / .catch / .finally, Promise.resolve / reject / all, new Promise) drained through a microtask queue, plus JSON.parse / stringify. The js shell command runs code inline (js -c "…", in-kernel for quick eval) or a script file (js FILE.js), which executes in ring 3 via the userland interpreter /bin/js (see Ring-3 browser & JS below).

Pages load over the kernel's own stack (DNS → TCP → TLS → HTTP/1.1):

  • http:// and https:// with cookies, redirects, keep-alive, and gzip / deflate content-encoding (net/inflate.c). DHCP (net/dhcp.c) auto- configures the network interface on boot (IP, gateway, DNS). HTTPS uses an in-kernel TLS 1.2 and 1.3 client (net/tls.c + net/crypto.c): ECDHE over X25519 / secp256r1 (P-256), AES-128-GCM-SHA256 and AES-256-GCM-SHA384. The server certificate chain is now verified (net/x509.c + net/rsa.c + net/p256.c / net/p384.c): RSA PKCS#1 v1.5 / PSS and ECDSA P-256 signatures, hostname and validity dates, against a small runtime trust-anchor store — so it resists an active MITM, not just passive eavesdropping.
  • local HTML files from the filesystem (e.g. the bundled /web/index.html).

Click links to navigate, type a URL in the address bar, < goes back, and the scrollbar / Space / b / j / k scroll. The data path rides the e1000 NIC driver (drivers/e1000.c) over QEMU/VirtualBox NAT, with a from-scratch stack: ARP, IPv4, ICMP, UDP, TCP, DNS, HTTP, a firewall (net/firewall.c), and TLS (net/*.c). Wi-Fi association is scaffolded in the kernel but still needs a radio driver — see the wifi command. The shell also has browse URL (render a page as text), download URL (save to the FS), and nstest (exercise NetSurf libraries).

OldBrowser — a NetSurf port

OldBrowser is a port of NetSurf — the small, fast, portable C web browser — onto BoltOS. NetSurf is built around a clean split between a portable core (content cache + handler pipeline + browser_window state machine) and per-platform frontends; OldBrowser reproduces that architecture faithfully. The port lives under oldbrowser/, with each file mapping to the NetSurf subsystem named in its banner:

OldBrowser file NetSurf module
ob_nsurl.c utils/nsurl.c + utils/url.c — URL object, RFC 3986 nsurl_join
ob_llcache.c content/llcache.c — fetch + redirect following, about: pages
ob_content.c content/content.c + handlers — text/html, text/plain, image/*
ob_window.c desktop/browser_window.c + browser_history.c — navigation, back/forward
ob_hotlist.c desktop/hotlist.c — bookmarks, persisted to the filesystem
ob_fbtk.c frontends/framebuffer/fbtk — the widget toolkit
ob_gui.c frontends/framebuffer/gui.c — toolbar, throbber, viewport, status bar
ns_html.c HTML parsing via libhubbub (vendored at netsurf/libhubbub/)
ns_select.c CSS selector matching via libcss (vendored at vendor/libcss-0.9.2/)

Where NetSurf leans on libdom and libcss, this port drives BoltOS's own DOM tree (kernel/dom.c) and CSS-cascade + box/flex/grid layout engine (kernel/layout.c) or the upstream libraries; where it uses libnsgif / libnspng, it calls the BoltOS image decoder (kernel/image.c); fetches ride the kernel HTTP/HTTPS stack (net/http.c). The result is the recognisable NetSurf chrome — a toolbar of Back / Forward / Reload / Stop / Home, an address bar, an animated throbber and a bookmark toggle — over a scrolling content viewport. Typed addresses that don't look like URLs become a web search; the about:welcome home page and about:credits render offline. The BoltOS window glue is kernel/app_oldbrowser.c.

IDE & compilers (BoltCC + BoltPy)

The Code app (kernel/app_ide.c) is a real in-kernel IDE: a text editor with a movable caret, line numbers, mouse click-to-place, scrolling, and live syntax highlighting, plus a language switcher and a Run button that compiles and executes the buffer, streaming the program's output into a console pane below.

  • BoltCC (kernel/boltcc.c) is a from-scratch C / C++ / C# compiler: one pipeline — lexer → recursive-descent parser → AST → stack bytecode → a bytecode VM. It genuinely compiles the source and runs the emitted bytecode (it is not a text interpreter). Shared across the three dialects: functions with recursion and forward references, int/char/long/bool/ string/var declarations, the full arithmetic / bitwise / comparison operator set with correct precedence, &&/||/! short-circuiting, ?:, ++/--, compound assignment, if/else/while/for/return/break/ continue, string concatenation and indexing, and builtins (len, str, int, abs, min, max, chr, ord). Per dialect:
    • Cprintf (real %d/%i/%u/%x/%c/%s/%% formatting), puts, putchar
    • C++std::cout << … << std::endl chains, using namespace, classes skipped
    • C#Console.WriteLine/Write (incl. {0} {1} formatting), using / namespace / class unwrapped, entry point Main()
  • BoltPy (kernel/boltpy.c) is a small Python-3 subset interpreter — the IDE's Python tab and the python shell command run on it. Integer arithmetic, variables, strings/lists, print, conditionals, while/for, def/recursion.
  • BoltRT (user/boltrt.c) is a PE32+ runtime stub that bakes BoltCC or BoltPython into a genuine Windows console executable — the compile shell command packs user source into this stub to produce a real .exe that runs on Windows 11 AND under BoltOS's PE loader.

The kernel has no FPU (SSE/x87 disabled), so every language here is integer + string only — there is no floating point.

TrueType fonts

kernel/ttf.c is a from-scratch TrueType rasterizer. It parses an embedded .ttf file (/sys/font.ttf), walks the cmap, head, hhea, hmtx, and glyf tables, and renders quadratic-bezier outlines to an anti-aliased 8-bit coverage bitmap using a non-zero winding scanline fill. The GUI uses it alongside the built-in 8×8 and 8×16 bitmap fonts — the Settings app lets the user switch between FONT_RETRO, FONT_ARIAL, and FONT_TTF.

Clipboard

kernel/clipboard.c provides a system-wide text clipboard shared by every GUI app. Copy in one window (Ctrl+C), paste in another (Ctrl+V). Backed by a single static buffer; the cap is CLIP_CAP bytes.

Multi-user

kernel/users.c implements a multi-user account table. Users are stored as name:hexhash:uid lines in /etc/passwd. The FS autosaves, so accounts survive reboots. The users shell command lists accounts; useradd / userdel add and remove them. Each user context is tracked by UID.

Package manager

kernel/pkg.c is a minimal package manager. Packages ship in a built-in catalog of BoltPython scripts. Installing one writes it to /apps/<name>.py and records the name in /var/lib/pkg/installed. Run an installed package with python /apps/<name>.py or pkg run <name>.

GPU / display driver

drivers/gpu.c probes the PCI bus for a display-class (0x03) controller, identifies the adapter from its vendor:device id (QEMU std-VGA, VirtualBox, VMware SVGA II, VirtIO-GPU, Cirrus, Intel, NVIDIA, AMD), decodes BAR0 to size the VRAM aperture, and detects the Bochs DISPI (VBE) interface for runtime mode setting. It backs the Graphics line in System Info and exposes a mode list + gpu_set_mode() (the linear framebuffer itself lives in drivers/framebuffer.c).

Windows executables (PE32+)

BoltOS can load and run real Windows x86-64 console .exe files. The loader (kernel/pe.c) parses the PE32+ headers, copies sections by RVA into a heap image, binds the import table against an in-kernel kernel32 shim (GetStdHandle, WriteConsoleA, WriteFile, ExitProcess, Heap*, … exposed with the Microsoft x64 ABI), and calls the entry point. The build compiles user/winhello.c into a genuine PE32+ with the mingw toolchain and also builds user/boltrt.c (BoltRT) — a full compiler/runtime stub — as a PE32+. Run from the shell with winrun (no args = the embedded demo, or winrun /path/to/app.exe). The image is position-independent (RIP-relative), so no base relocations are needed once imports are bound.

DOOM

BoltOS runs real DOOM. The doomgeneric port lives under doom/, built against a tiny in-house freestanding libc shim (doom/dg_libc.c) and a BoltOS platform layer (doom/doomgeneric_boltos.c); the shareware WAD is embedded in the kernel image as a blob. The DOOM desktop app (kernel/app_doom.c) pumps the engine, routes keyboard input, and blits the engine's 640×400 framebuffer into its window — E1M1 is playable. As everywhere else there is no FPU, so the port is driven with integer math only.

USB (xHCI)

An xHCI USB host-controller driver (drivers/xhci.c) brings up the controller (DCBAA, command ring, single-segment event ring, scratchpad buffers) and, for each connected root-hub port, resets it, issues Enable Slot / Address Device, and walks EP0 control transfers to read the device and configuration descriptors. Enumerated devices (including HID keyboards and mice) are reported at boot. Enumeration runs polled (a bounded one-time sequence), then HID input switches to hardware interrupts: interrupter 0 + USBCMD.INTE are enabled and an MSI/MSI-X vector is routed to the IDT, so keyboard/mouse boot reports arrive as IRQs (the handler drains the event ring) instead of being polled from the idle loop. Controllers without MSI stay on the polled path.

Freestanding libc

BoltOS now ships a full freestanding C library (libc/) that both the kernel and userland programs link against:

File Provides
string.c memcpy, memset, strlen, strcmp, strcpy, …
string_ext.c strdup, strtok, strchr, strrchr, strstr, …
malloc.c malloc, free, realloc, calloc (simple heap)
printf.c printf, sprintf, snprintf, vprintf, …
scanf.c scanf, sscanf, vscanf
stdlib.c atoi, atol, rand, qsort, abs, bsearch, …
math.c sqrt, sin, cos, tan, atan2, exp, log, …
stdio_file.c fopen, fread, fwrite, fclose, fseek, ftell
time.c time, localtime, mktime, clock, RTC integration
setjmp.S setjmp / longjmp (assembly)
support.c __assert_fail, __stack_chk_fail

Built with -fstack-protector-strong and -fno-math-errno for kernel compatibility.

StackGuard (stack canaries)

kernel/stackguard.c provides stack-smashing protection. The kernel is built with -fstack-protector-strong -mstack-protector-guard=global, so the compiler inserts a canary into every function with stack buffers and checks it on return. A mismatch triggers __stack_chk_fail() — a kernel panic. The canary is re-seeded early in boot from the timestamp counter, making it unpredictable per boot.

Boot flow (from scratch)

Legacy BIOS boot:

BIOS ── loads ──▶ stage1.asm (512 B MBR @ 0x7C00)
                      │ INT 13h LBA read
                      ▼
                  stage2.asm (@ 0x8000, real mode)
                      │  enable A20
                      │  BIOS E820 memory map
                      │  unreal mode → copy kernel to 1 MiB
                      │  build PML4/PDPT/PD (identity 0..4 GiB, 2 MiB pages)
                      │  enter long mode
                      ▼
                  kernel/boot.asm (_start, 64-bit @ 0x100000)
                      │  set stack, zero BSS
                      ▼
                  kmain(bootinfo)   ← kernel/main.c

UEFI boot:

UEFI firmware ── loads ──▶ boot/uefi_boot.c (BOOTX64.EFI)
                              │  locate GOP handle → framebuffer
                              │  build UEFI memory map → E820-like table
                              │  build page tables (identity + higher-half)
                              │  enter long mode, jump to 0x100000
                              ▼
                          kernel/boot.asm (_start, 64-bit)
                              │  set stack, zero BSS
                              ▼
                          kmain(bootinfo)   ← kernel/main.c

The kernel is a higher-half kernel: it is linked at virtual 0xFFFFFFFF80100000 (linker.ld, KERNEL_VBASE = 0xFFFFFFFF80000000) but its load address (LMA) is physical 0x100000, so ld.lld --oformat binary still emits a flat image that loads at phys 1 MiB. The bootloader (stage2 / UEFI loader) maps the top 2 GiB of the address space to physical 0 before entering the kernel; boot.asm then jmps from the identity-mapped entry to its linked higher-half address and runs from the higher half thereafter, with a direct physical map at PHYS_BASE. bootinfo (framebuffer + E820 map) is handed to the kernel in RDI and lives at physical 0x0500.

Toolchain (Windows / msys2)

  • nasm — bootloader, kernel asm, userland crt0, and SMP AP trampoline
  • clang --target=x86_64-elf — freestanding kernel + userland C (native cross-compiler)
  • clang --target=x86_64-w64-mingw32 — builds user/winhello.c into a real PE32+ .exe and user/boltrt.c into the BoltRT compiler stub
  • clang --target=x86_64-unknown-windows — builds boot/uefi_boot.c into a UEFI application (BOOTX64.EFI)
  • ld.lld — link kernel to a flat binary and the user program to a static ELF64
  • qemu-system-x86_64 — run / test (supports both legacy and UEFI with OVMF)

Build & run

bash build.sh              # -> iso/os.img (+ bootable iso/boltos.iso, UEFI bootable)
bash run.sh                # boot in QEMU, kernel output on serial (stdio)
bash run-uefi.sh           # boot with UEFI firmware (OVMF) instead of legacy BIOS

build.sh also:

  • Assembles + links user/hello.c into a static ELF64
  • Compiles user/winhello.c into a real PE32+ .exe
  • Builds user/boltrt.c into a BoltRT PE32+ compiler stub
  • Builds boot/uefi_boot.c into a UEFI application (BOOTX64.EFI)
  • Embeds all of them in the kernel image as blobs
  • Compiles the full DOOM engine from source into the kernel

PowerShell helpers (rebuild-all.ps1, rebuild-vdi.ps1, build-and-run-vbox.bat) build VirtualBox-friendly images. read-serial.ps1 captures serial output on Windows; shot_uefi.py captures UEFI framebuffer screenshots.

Layout

boot/           Custom boot loaders: stage1 + stage2 (legacy MBR) + uefi_boot.c (UEFI)
doom/           Vendored doomgeneric port + in-house libc shim + BoltOS platform layer
oldbrowser/     NetSurf port (OldBrowser): nsurl, content cache + handlers, browser_window, fbtk frontend,
                libhubbub HTML parsing, libcss selector integration
drivers/        Hardware drivers (framebuffer, GPU/display, keyboard, mouse, ATA HDD/SSD, AHCI SATA,
                NVMe, xHCI USB, e1000 NIC, PC speaker, AC97 audio)
fs/             Filesystems: BoltFS (in-RAM tree, persisted), EXT2 (read-only), FAT32 (read/write)
include/        80+ kernel/system headers (blk, dom, layout, js, acpi, apic, smp, ahci, ext2, fat32,
                ttf, clipboard, users, audio, dhcp, nvme, xhci, rsa, x509, ...)
kernel/         Core kernel: scheduler, processes, syscalls, ELF + PE loaders, block layer, ACPI, APIC,
                SMP, HPET, GUI + 24 apps, shell, browser engine (DOM/layout), BoltCC compilers, JS + Python
                interpreters, package manager, multi-user, clipboard, TTF renderer, stack canaries
libc/           Freestanding C library (string, malloc, printf, scanf, stdlib, math, stdio, time, setjmp)
mm/             Memory management (PMM, heap, virtual memory, DMA, swap)
net/            Network stack (ARP, IP, ICMP, UDP, TCP, DNS, DHCP, HTTP, TLS 1.2/1.3, crypto, RSA,
                X.509, inflate, firewall, e1000 glue, Wi-Fi)
netsurf/        Vendored NetSurf libraries (libhubbub HTML parser, libparserutils, libwapcaplet)
user/           Ring-3 userland program (crt0, ulibc, boltrt) -> static ELF64 + PE32+ runtime stub
vendor/         Vendored libraries (libcss-0.9.2 CSS parsing/selection)
linker.ld       Flat-binary kernel layout @ 0x100000
build.sh        Full build script → raw disk image + bootable ISO + UEFI boot
run.sh          QEMU launcher (legacy BIOS)
run-uefi.sh     QEMU launcher (UEFI with OVMF)

Project Stats

First-party code (excludes the vendored doom/ doomgeneric port, vendor/ libcss, and netsurf/ libraries):

  • Total Lines of Code: ~41,000
    • C: ~36,340 lines
    • Headers: ~3,870 lines
    • Assembly: ~870 lines
    • Shell Scripts: ~460 lines
    • Linker Scripts: 62 lines
    • Python (build/test tools): ~220 lines

Available Shell Commands

The interactive OS shell supports a wide range of commands:

  • File & Directory: ls, tree, cd, mkdir, rm, cp, mv, find, trash, recover, pwd, touch, write
  • File Inspection: cat, head, tail, hex, meta, diff, grep, checksum, preview, count
  • System Information: sysinfo, cpuinfo, meminfo, diskinfo, sync, uptime, battery, sensors, devices, version, health
  • Process Management: ps, kill, top, freeze, resume, services, service, jobs, priority, monitor
  • System (cont.): winrun (Windows PE32+ loader), compile (BoltRT: compile a source file into a real PE32+ .exe), pkg (package manager), users / useradd / userdel (multi-user), libctest (libc validation)
  • Networking: netinfo, ping, trace, ports, download, browse, webx (ring-3 web browser), upload, wifi, firewall, share, scan, nstest (NetSurf library test)
  • Language: python (BoltPy interpreter / REPL), js (BoltJS interpreter, js -c "…" or js FILE.js); the Code app compiles C / C++ / C#
  • Bonus / Unique: focus, snapshot, timeline, vault, doctor, assistant, sandbox, workspace, panic, story
  • Core: help, echo, clear, mem

Full File Tree

+-- README.md
+-- BROWSER_UPGRADE.md     Browser engine upgrade plan + status log
+-- build.sh  run.sh  run-uefi.sh    Build and QEMU launchers (legacy + UEFI)
+-- build-and-run-vbox.bat  rebuild-all.ps1  rebuild-vdi.ps1  read-serial.ps1
+-- shot.py  testnet.py  shot_uefi.py    GUI screendump + network test harnesses
+-- linker.ld
+-- boot/
|   +-- stage1.asm  stage2.asm  uefi_boot.c
+-- doom/                  Full doomgeneric port (~150 files, includes libc shim)
+-- drivers/
|   +-- ac97.c     ahci.c    ata.c     e1000.c
|   +-- framebuffer.c  gpu.c  keyboard.c  mouse.c
|   +-- nvme.c     pcspk.c   xhci.c
+-- fs/
|   +-- ramfs.c            BoltFS
|   +-- ext2.c             EXT2 (read-only)
|   +-- fat32.c             FAT32 (read/write)
+-- include/               80+ kernel/system headers
+-- kernel/
|   +-- main.c   boot.asm  shell.c        console.c   gui.c       hw.c
|   +-- sched.c  proc.c    syscall.c/.asm  elf.c       pe.c        idt.c
|   +-- interrupts.c  isr.asm  pic.c  pit.c  pci.c  serial.c  settings.c  vfs.c
|   +-- acpi.c   apic.c    smp.c   ap_boot.asm   hpet.c  gdt.c  stackguard.c
|   +-- blk.c             Generic block layer (ATA/AHCI/NVMe registry + MBR helpers)
|   +-- dom.c   layout.c  html.c          Browser engine: DOM tree, CSS cascade, box/flex/grid layout
|   +-- js.c    cmd_js.c  boltcc.c  boltpy.c   JavaScript, C/C++/C#, Python
|   +-- image.c  font8x8.c  kprintf.c  sysreg.c  user.asm
|   +-- ttf.c    clipboard.c  users.c  pkg.c
|   +-- cmd_extra.c  cmd_fs.c  cmd_net.c  cmd_proc.c  cmd_python.c  cmd_sys.c  cmd_hw.c
|   +-- cmd_js.c  cmd_libctest.c  cmd_nstest.c
|   \-- app_*.c           24 desktop apps (browser, files, ide, taskmgr, doom, paint, games, ...)
+-- libc/
|   +-- string.c  string_ext.c  malloc.c  printf.c  scanf.c
|   +-- stdlib.c  math.c  stdio_file.c  time.c  support.c
|   \-- setjmp.S
+-- mm/
|   +-- dma.c  kheap.c  pmm.c  vmm.c
+-- net/
|   +-- arp.c   eth.c    ip.c    icmp.c  udp.c   tcp.c   dns.c   netif.c  dhcp.c
|   +-- http.c  inflate.c  firewall.c  driver.c  firmware.c  wifi.c
|   +-- tls.c   crypto.c  rsa.c   x509.c  p256.c  p384.c     TLS 1.2/1.3 + cert verification
+-- netsurf/              Vendored NetSurf libraries (libhubbub, libparserutils, libwapcaplet)
+-- vendor/               Vendored libcss-0.9.2 (CSS parsing/selection)
\-- user/
    +-- crt0.asm  hello.c  winhello.c  boltrt.c    Ring-3 ELF64 + PE32+ demos
    +-- js_main.c  browser_main.c  kheap.h         Ring-3 JS interpreter + web browser (DOM+layout+JS)
    +-- ulibc.c/.h  stdlib_ext.c  libm.c
    +-- stdio.h  stdlib.h  math.h  ctype.h
    \-- user.ld

About

BoltOS is an ambitious, actively developed operating system written entirely from scratch in C and x86-64 assembly. It stands out by requiring no external bootloaders (like GRUB), no Multiboot specifications, and no external libraries. Instead, it features a custom dual-path boot chain that supports both legacy BIOS (MBR) and modern UEFI firmware.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors