DOCS

.gitignore

@@ -20,7 +20,6 @@ limine 2/limine.dSYM/Contents/Resources/DWARF/limine
 limine 2/limine.exe
 boredos.dump
 qemu-debug.log
-build/
 iso_root/
 limine/
 src/userland/bin/
@@ -30,3 +29,4 @@ limine
 .DS_Store
 src/.DS_Store
 limine
+/build/

README.md

@@ -31,95 +31,15 @@ It features a DE (and WM), a FAT32 filesystem, customizable UI and much much mor
 - CLI
 - (Limited) C Compiler
 
-## Prerequisites
+## Documentation
 
-To build BoredOS, you'll need the following tools installed:
+BoredOS has comprehensive documentation available in the [`docs/`](docs/) directory covering architecture, the build system, and application development SDKs.
 
-- **x86_64 ELF Toolchain**: `x86_64-elf-gcc`, `x86_64-elf-ld`
+-   **[Index / Table of Contents](docs/README.md)**
-- **NASM**: Netwide Assembler for compiling assembly code
+-   **[Architecture Overview](docs/architecture/core.md)**
-- **xorriso**: For creating bootable ISO images
+-   **[Building and Running](docs/build/usage.md)**
-- **QEMU** (optional): For testing the kernel in an emulator
+-   **[Application Development Guide](docs/appdev/custom_apps.md)**
 
-On macOS, you can install these using Homebrew:
-```sh
-brew install x86_64-elf-binutils x86_64-elf-gcc nasm xorriso qemu
-```
-
-## Building
-
-Simply run `make` from the project root:
-
-```sh
-make
-```
-
-This will:
-1. Compile all kernel C sources and assembly files
-2. Link the kernel ELF binary
-3. Generate a bootable ISO image (`boredos.iso`)
-
-The build output is organized as follows:
-- Compiled object files: `build/`
-- ISO root filesystem: `iso_root/`
-- Final ISO image: `boredos.iso`
-
-## Running
-
-### QEMU Emulation
-
-Run the kernel in QEMU:
-
-```sh
-make run
-```
-
-Or manually:
-```sh
-qemu-system-x86_64 -m 2G -serial stdio -cdrom boredos.iso -boot d
-```
-
-### Running on Real Hardware
-
-*Warning: This is at YOUR OWN RISK. This software comes with ZERO warranty and may break your system.*
-
-1. **Create bootable USB**: Use [Balena Etcher](https://www.balena.io/etcher/) to flash `boredos.iso` to a USB drive
-
-2. **Prepare the system**:
-   - Enable legacy (BIOS) boot in your system BIOS/UEFI settings
-   - Disable Secure Boot if needed
-
-3. **Boot**: Insert the USB drive and select it in the boot menu during startup
-
-**Networking requires an Intel E1000 network card or similar while using Ethernet.**
-
-4. **Tested Hardware**:
-   - HP EliteDesk 705 G4 DM (AMD Ryzen 5 PRO 2400G, Radeon Vega) **Tested, no networking.**
-   - Lenovo ThinkPad A475 20KL002VMH (AMD Pro A12-8830B, Radeon R7) **Tested, no networking.**
-   - Acer Aspire E5-573-311M (Intel Core i3-5005U, Intel HD Graphics) **Tested, no networking.**
-
-
-## Project Structure
-
-- `src/` - Main OS codebase
-  - `arch/` - Assembly bootstrap and interrupt architectures
-  - `core/` - Initialization, commands, system panic
-  - `dev/` - PCI, disk manager, inputs, and RTC 
-  - `fs/` - Physical and virtual filesystems (FAT32)
-  - `mem/` - Memory management, paging, and VM
-  - `net/` - Networking stack, interface controllers, and `lwip/`
-  - `sys/` - System calls, process management, and ELF loader
-  - `wm/` - Graphics, user interface, fonts, and window manager
-  - `userland/` - End-user applications and tools
-    - `cli/` - Standard command line applications
-    - `gui/` - Graphical applications
-    - `games/` - Games such as DOOM and Minesweeper
-    - `sys/` - Userland system tools and network clients
-- `build/` - Compiled object files (generated during build)
-- `iso_root/` - ISO filesystem layout (generated during build)
-- `limine/` - Limine bootloader files (downloaded automatically)
-- `linker.ld` - Linker script for x86_64 ELF
-- `limine.conf` - Limine bootloader configuration
-- `Makefile` - Build configuration and targets
 
 
 

docs/README.md

@@ -0,0 +1,25 @@
+# BoredOS Documentation
+
+Welcome to the internal documentation for BoredOS! This directory contains detailed guides on how the OS functions, how to build it, and how to develop applications for it.
+
+## Table of Contents
+
+The documentation is organized into three main categories:
+
+### 1. [Architecture](architecture/)
+Explains the logical layout of the kernel and internal components.
+-   [`Core`](architecture/core.md): Kernel source layout and the boot process (Limine, Multiboot2).
+-   [`Memory`](architecture/memory.md): Physical Memory Management (PMM) and Virtual Memory Management (VMM).
+-   [`Filesystem`](architecture/filesystem.md): Virtual File System (VFS) and the RAM-based FAT32 simulation.
+-   [`Window Manager`](architecture/window_manager.md): How the built-in Window Manager natively handles graphics, events, and compositing.
+
+### 2. [Building and Deployment](build/)
+Instructions for compiling the OS from source.
+-   [`Toolchain`](build/toolchain.md): Prerequisites and cross-compiler setup (`x86_64-elf-gcc`, `nasm`, `xorriso`).
+-   [`Usage`](build/usage.md): Understanding the Makefile targets, QEMU emulation, and flashing to bare metal hardware.
+
+### 3. [Application Development](appdev/)
+The SDK and toolchain guides for creating your own `.elf` userland binaries.
+-   [`SDK Reference`](appdev/sdk_reference.md): Explanation of the custom `libc` wrappers (`stdlib.h`, `string.h`) and system calls.
+-   [`UI API`](appdev/ui_api.md): Drawing on the screen, creating windows, and polling the event loop using `libui.h`.
+-   [`Custom Apps`](appdev/custom_apps.md): A step-by-step tutorial on writing a new graphical C application, editing the Makefile, and bundling it into the ISO.

docs/appdev/custom_apps.md

@@ -0,0 +1,78 @@
+# Creating a Custom App (Step-by-Step)
+
+This guide explains how to write a new "Hello World" application locally, compile it as an `.elf` binary into the `bin/` folder, and launch it inside BoredOS.
+
+## Step 1: Write the C Source
+
+Applications reside entirely in the `src/userland/` directory. Create a new file, for example, `src/userland/gui/hello.c`.
+
+> [!TIP]
+> Group CLI apps into `src/userland/cli/` and windowed apps into `src/userland/gui/` for organization.
+
+```c
+// src/userland/gui/hello.c
+#include <stdlib.h>
+#include <libui.h>
+
+int main(void) {
+    // Attempt to open a 300x200 window
+    int wid = ui_create_window("My Custom App", 300, 200, 0);
+    if (wid < 0) {
+        printf("Error creating window!\n");
+        return 1;
+    }
+    
+    // Write text in center
+    ui_draw_string(wid, "Hello, BoredOS!!", 50, 90, 0xFFFFFFFF);
+    
+    // Commit drawing to screen
+    ui_swap_buffers(wid);
+
+    ui_event_t event;
+    while (1) {
+        if (ui_poll_event(&event)) {
+            if (event.window_id == wid && event.type == UI_EVENT_WINDOW_CLOSE) {
+                break; // Exit loop if 'X' is clicked
+            }
+        }
+        
+        syscall1(SYSTEM_CMD_YIELD, 0);
+    }
+
+    return 0; // Returning 0 smoothly exits the process via crt0.asm
+}
+```
+
+## Step 2: Edit the Makefile
+
+Now you need to tell the build system to compile `hello.c`. Fortunately, the `src/userland/Makefile` is designed to detect new C files largely automatically!
+
+1.  Open `src/userland/Makefile`.
+2.  Find the line specifying `APP_SOURCES_FULL`:
+    ```make
+    APP_SOURCES_FULL = $(wildcard cli/*.c gui/*.c sys/*.c games/*.c *.c)
+    ```
+    Since you placed the file in `gui/hello.c`, the wildcard logic will pick it up automatically.
+3.  The Makefile will generate `bin/hello.elf` during the build phase.
+
+## Step 3: Bundle it into the OS
+
+The main overarching `Makefile` (in the project root) takes binaries from `src/userland/bin/*.elf` and places them into the `iso_root/bin/` directory, while also adding them to `limine.conf` as loadable boot modules.
+
+1.  Go back to the root of the OS:
+    ```sh
+    cd ../..
+    ```
+2.  Compile the entire project to build the ISO and test in QEMU:
+    ```sh
+    make clean && make run
+    ```
+
+## Step 4: Run it inside BoredOS
+
+1.  When BoredOS boots, launch the **Terminal** application.
+2.  The OS automatically maps built applications to standard shell commands. Simply type your application's filename (without the `.elf` extension).
+3.  Type `hello` in the terminal and press Enter.
+4. Your custom window will appear!
+
+*you can also open your app by opening the file explorer and navigating to the bin directory and double clicking the executable.*

docs/appdev/sdk_reference.md

@@ -0,0 +1,36 @@
+# Userland SDK Reference
+
+BoredOS provides a custom `libc` implementation necessary for writing userland applications (`.elf` binaries). By avoiding a full-blown standard library like `glibc`, the OS ensures a minimal executable footprint tailored strictly to the existing kernel features.
+
+## The Custom libc Structure (`src/userland/libc/`)
+
+The SDK comprises a few key files containing wrappers around kernel system calls:
+
+-   `stdlib.h` / `stdlib.c`: Memory allocation (`malloc`, `free`), integer conversion (`itoa`, `atoi`), printing (`printf`, `sprintf`), and random numbers (`rand`, `srand`).
+-   `string.h` / `string.c`: String manipulation utilities (`strlen`, `strcpy`, `strcmp`, `memset`, `memcpy`).
+-   `syscall.h` / `syscall.c`: The raw interface to issue `syscall` assembly instructions, routing requests to the kernel.
+-   `libui.h` / `libui.c`: Graphical interface commands (creating windows, drawing pixels, events).
+
+## System Calls Overview
+
+When a userland application wants to interact with the hardware (print to screen, read a file, create a window), it must ask the kernel via a **System Call**.
+
+In BoredOS (`x86_64`), system calls are issued using the `syscall` instruction. The kernel intercepts this instruction and inspects the processor's RAX register to figure out *what* the application wants to do.
+
+The custom `libc` provides `syscallX` wrapper functions that abstract the assembly details:
+```c
+// Example: Performing a minimal system call from userland
+int sys_write(int fd, const char *buf, int len) {
+    return syscall3(SYS_WRITE, fd, (uint64_t)buf, len);
+}
+```
+
+### Notable System Calls
+
+-   **`SYS_WRITE` (1)**: Currently acts as a generic output mechanism for `printf`, typically routing text to the kernel's serial output for debugging, or to an active text-mode console.
+-   **`SYS_GUI` (3)**: The primary multiplexer for all window manager operations. The arguments define subcommands (like `UI_CREATE_WINDOW`, `UI_FILL_RECT`).
+-   **`SYS_FS` (4)**: Interacts with the virtual filesystem (e.g., `FS_CMD_OPEN`, `FS_CMD_READ`). Under the hood, this reads from the loaded RAMFS or an attached physical ATA disk via the native FAT32 driver.
+-   **`SYS_EXIT` (60)**: Terminates the current process and returns control to the kernel.
+-   **`SYSTEM_CMD_YIELD` (43)**: Instructs the process scheduler to pause the current process and let another process run.
+
+If you are developing a new application, **do not invoke syscalls manually**. Instead, include `stdlib.h` and use the C functions provided.

docs/appdev/ui_api.md

@@ -0,0 +1,85 @@
+# UI API (`libui.h`)
+
+For an application to be visible on the screen, it must interact with the BoredOS Window Manager (WM). The tools required for this are located in `src/userland/libc/libui.h` and `libui.c`.
+
+## Core Concepts
+
+The UI library sends requests (via `SYS_GUI`) to the kernel to reserve an area on the screen (a `Window`) and then issues commands to color specific pixels within that area. The kernel is responsible for compositing this area over other windows.
+
+## Example: Creating a Window
+
+First, include the library and define an event structure:
+
+```c
+#include <libui.h>
+#include <stdlib.h>
+
+int main(void) {
+    // 1. Create the window
+    // Arguments: Title, Width, Height, Flags (e.g. 0 for bordered window)
+    int window_id = ui_create_window("Hello World App", 400, 300, 0);
+
+    if (window_id < 0) {
+        printf("Failed to create window!\n");
+        return 1;
+    }
+
+    // ... Event loop will go here ...
+    return 0;
+}
+```
+
+## Drawing Primitives
+
+The library offers functions to mutate the window's internal buffer. After issuing drawing commands, you **must** instruct the kernel to push the changes onto the screen.
+
+```c
+// Fill the entire window with a solid blue background
+// Arguments: Window ID, X, Y, Width, Height, ARGB Color value
+ui_fill_rect(window_id, 0, 0, 400, 300, 0xFF0000FF);
+
+// Tell the kernel to commit the drawing commands to the screen
+ui_swap_buffers(window_id);
+```
+
+Available rendering methods:
+-   `ui_fill_rect(id, x, y, w, h, color)`: Draw a solid rectangle.
+-   `ui_draw_rect(id, x, y, w, h, color)`: Draw an outline of a rectangle.
+-   `ui_draw_line(id, x0, y0, x1, y1, color)`: Bresenham line algorithm.
+-   `ui_draw_string(id, string, x, y, color)`: Render text using the kernel's built-in font.
+-   `ui_update_region(id, x, y, w, h)`: A targeted version of `ui_swap_buffers` that only updates a specific area, saving performance.
+
+## Handling the Event Loop
+
+Graphical applications are event-driven. They stay alive inside a `while (1)` loop, periodically asking the kernel if the user clicked the mouse or pressed a key inside their window.
+
+```c
+    ui_event_t event;
+
+    // Main UI Loop
+    while (1) {
+        // ui_poll_event is non-blocking. It returns 1 if an event occurred, 0 otherwise.
+        if (ui_poll_event(&event)) {
+            
+            // The WM dispatch sets event.window_id 
+            // We only care about events meant for our specific window
+            if (event.window_id == window_id) {
+
+                if (event.type == UI_EVENT_MOUSE_DOWN) {
+                    printf("User clicked at X:%d Y:%d\n", event.mouse_x, event.mouse_y);
+                    
+                    // Respond visually to the click
+                    ui_fill_rect(window_id, event.mouse_x, event.mouse_y, 10, 10, 0xFFFF0000); // Red dot
+                    ui_swap_buffers(window_id);
+                } 
+                else if (event.type == UI_EVENT_WINDOW_CLOSE) {
+                    // Start tearing down the application safely
+                    break;
+                }
+            }
+        }
+        
+        // Prevent 100% CPU usage by yielding execution time back to the OS scheduler
+        syscall1(SYSTEM_CMD_YIELD, 0);
+    }
+```

docs/architecture/core.md

@@ -0,0 +1,39 @@
+# Core Architecture
+
+BoredOS is a 64-bit hobbyist operating system designed for the x86_64 architecture. While it features kernel-space drivers and a built-in window manager, it supports fully-isolated userspace applications and includes a networking stack.
+
+This document serves as an overview of the core architecture and the layout of the kernel source code.
+
+## Source Code Layout (`src/`)
+
+The OS heavily relies on module separation. The `src/` directory is logically split into several domains:
+
+- **`arch/`**: Contains the assembly routines needed for bootstrapping the system (`boot.asm`) and setting up the CPU state for userland execution (`process_asm.asm`). It also handles architecture-specific mechanisms like the Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT).
+- **`core/`**: The initialization sequence of the OS lives here. `main.c` is the entry point from the bootloader. This directory also contains essential kernel utilities (`kutils.c`), panic handlers (`panic.c`), and built-in command parsing logic (`cmd.c`).
+- **`dev/`**: Device drivers. This includes the PCI scanner, disk management infrastructure, input drivers (keyboard and mouse), and the Real Time Clock (RTC).
+- **`fs/`**: Filesystem implementations. The system uses a Virtual File System (VFS) abstraction alongside an in-memory FAT32 filesystem with support for drives over ATA that are formatted as FAT32 (plain/MBR).
+- **`mem/`**: Physical and virtual memory management. It controls page frame allocation, paging, and kernel heap operations.
+- **`net/`**: The networking stack. BoredOS relies on `lwIP` for processing IPv4 and TCP/UDP traffic, interacting with a range of NICs via `net/nic/`.
+- **`sys/`**: System calls and process management. The ELF loader resides here, parsing userland binaries and setting them up for execution.
+- **`wm/`**: The graphical subsystem. It handles drawing primitives, window structures, font rendering, and double-buffering.
+- **`userland/`**: Out-of-kernel components. This includes the custom SDK/compiler environment (`libc/`) and user applications (`cli/`, `gui/`, `games/`).
+
+## Boot Process
+
+BoredOS uses **Limine** as its primary bootloader.
+
+1.  **Limine Initialization**: The machine firmware (BIOS or UEFI) loads Limine. Limine parses `limine.conf`, sets up an early graphical framebuffer, and reads the kernel ELF file into memory.
+2.  **Multiboot2 Protocol**: The kernel expects the Limine boot protocol (which is compatible with modern Multiboot specifications). Passing a framebuffer and memory map is handled natively by Limine's request structures (defined locally via `limine.h`).
+3.  **Kernel Entry (`main.c`)**: The entry point `_start` is called. It immediately initializes the serial port for debugging, sets up core structures (GDT/IDT), initializes the physical memory manager based on the Limine memory map, and starts the virtual memory manager.
+4.  **Driver Initialization**: PCI buses are scanned, finding the network card or disk controllers. The filesystem is mounted.
+5.  **Window Manager**: The UI is drawn on top of the Limine-provided framebuffer.
+
+## Userland Transition
+
+The OS supports privilege separation (Ring 0 vs. Ring 3). When an application (like `browser.elf` or `viewer.elf`) is launched, the kernel:
+1.  Loads the ELF file from the filesystem using the ELF parser in `sys/elf.c`.
+2.  Allocates a new virtual address space (Page Directory) for the process.
+3.  Maps the executable segments according to the ELF headers.
+4.  Switches to User Mode (Ring 3) via the `iretq` instruction, jumping into the application's entry point (`crt0.asm`).
+
+Programs then interact with the core kernel using system calls (`syscall.c`).

docs/architecture/filesystem.md

@@ -0,0 +1,28 @@
+# Filesystem Architecture
+
+BoredOS implements a rudimentary but functional filesystem layer designed to support reading system assets and user applications during runtime.
+
+## Virtual File System (VFS)
+
+The Virtual File System acts as an abstraction layer across different underlying storage mechanisms (even if, currently, only one type is fully utilized). System calls targeting files (`SYS_FS`) route through the VFS rather than interacting with the disk directly.
+
+Key VFS functionalities include:
+-   **File Descriptors**: Mapping integer IDs to internal file structures for userland processes.
+-   **Standard Operations**: Standardizing `open()`, `read()`, `write()`, `close()`, `seek()`, and directory listings.
+-   **Path Parsing**: Resolving absolute and relative paths.
+
+## FAT32 Implementation
+
+The primary filesystem logic in `fat32.c` has a dual nature, supporting both an in-memory RAM filesystem for booting and standard block devices for external storage.
+
+### Booting and the RAMFS
+Since BoredOS boots from a CD-ROM ISO image generated by `xorriso`, it does not read directly off the CD to execute applications.
+1.  **ISO Booting**: During boot, Limine loads necessary files (such as userland `.elf` binaries, fonts, and wallpapers) into memory as standard boot modules.
+2.  **RAM Simulation**: The FAT32 filesystem code parses these loaded memory modules and automatically constructs a synthetic FAT32 directory tree inside RAM.
+3.  **Root Filesystem**: All active execution of built-in GUI and CLI apps occurs off this read-only, in-memory FAT32 simulation.
+
+### ATA Disk Support
+Beyond the core RAMFS used for booting, the FAT32 implementation natively supports interacting with permanent storage:
+1.  **ATA Block Driver**: The kernel features an ATA block device driver capable of communicating with physical hard disks (or raw disk images attached via QEMU).
+2.  **Partition Compatibility**: The driver can recognize and natively mount external ATA disks formatted as single FAT32 filesystems or structured with a Master Boot Record (MBR) partition table.
+3.  **VFS Integration**: When external storage is mounted, the VFS delegates operations down directly to the FAT32 driver, which will read native sectors across the ATA interface.

docs/architecture/memory.md

@@ -0,0 +1,23 @@
+# Memory Management
+
+Memory management in BoredOS is split into physical and virtual layers, designed to support both kernel operations and userland isolation on the x86_64 architecture.
+
+## Physical Memory Management (PMM)
+
+The PMM is responsible for tracking which physical RAM frames (usually 4KB each) are free and which are in use.
+
+1.  **Memory Map**: During boot, Limine provides a memory map detailing the available, reserved, and unusable physical memory regions.
+2.  **Bitmap Allocator**: The core PMM uses a bitmap-based allocation strategy. Each bit in the bitmap represents a single physical page (frame). If a bit is `1`, the page is in use; if `0`, it is free.
+3.  **Allocation**: When a new page is requested (e.g., for userland space or kernel heap), the PMM scans the bitmap for the first available zero bit, marks it as used, and returns the physical address.
+
+## Virtual Memory Management (VMM) and Paging
+
+BoredOS uses 4-level paging (PML4), a requirement for x86_64 long mode, dividing the virtual address space between the kernel and userland.
+
+-   **Kernel Space**: The kernel relies on a higher-half design where its code, data, and heap are mapped to high addresses (typically above `0xFFFF800000000000`). This ensures the kernel remains mapped and accessible regardless of which user process is currently active.
+-   **User Space**: Userland applications are loaded into lower virtual addresses (starting frequently around `0x40000000`).
+-   **Page Faults**: The `mem/` subsystem registers an Interrupt Service Routine (ISR) for page faults (Interrupt 14). If a process accesses unmapped memory, the handler determines whether to allocate a new frame (e.g., for stack growth or lazy loading) or terminate the process for a segmentation fault.
+
+## Kernel Heap
+
+Dynamic allocation within the kernel (`kmalloc` and `kfree`) is layered on top of the physical allocator. The kernel maintains its own heap area in virtual memory. When the heap requires more space, it requests physical frames from the PMM and maps them into the kernel's virtual address space using the VMM.

docs/architecture/window_manager.md

@@ -0,0 +1,33 @@
+# Window Manager (WM)
+
+BoredOS features a fully custom, graphical Window Manager built directly into the kernel, residing in the `src/wm/` directory. It is responsible for compositing the screen, handling window logic, rendering text, and dispatching UI events.
+
+## Framebuffer and Rendering
+
+1.  **Limine Framebuffer**: During boot, the Limine bootloader requests a graphical framebuffer from the hardware (e.g., GOP in UEFI environments) and passes a pointer to this linear memory buffer to the kernel.
+2.  **Double Buffering**: To prevent screen tearing, the WM does not draw directly to the screen. It allocates a "back buffer" in kernel memory equal to the size of the screen. All drawing operations (lines, rectangles, windows) happen on this back buffer.
+3.  **Compositing**: Once per frame or upon request, the entire back buffer (or dirty regions) is copied to the actual Limine physical framebuffer memory, making the changes visible instantly.
+
+## Window System (`wm.c`)
+
+The windowing system is built around a linked list of `Window` structures.
+
+-   **Z-Ordering**: The list determines the draw order. Windows at the back of the list are drawn first, and the active window is drawn last (on top).
+-   **Window Structures**: Each window object tracks its dimensions (`x`, `y`, `width`, `height`), title, background color, and an internal buffer if it's acting as a canvas for userland apps.
+-   **Decorations**: The kernel handles drawing window borders, title bars, and close buttons automatically unless a borderless style is specified.
+
+## Input Handling and Events
+
+The WM acts as the central hub for input routing.
+
+1.  **Mouse Driver**: The PS/2 mouse driver (`dev/mouse.c`) detects movement and button clicks. It raises interrupts that update global cursor coordinates.
+2.  **Hit Testing**: The WM checks these coordinates against the bounding boxes of existing windows. It handles dragging logic (if the user clicks a title bar) or focus changes.
+3.  **Event Queue**: If a userland application owns the window that was clicked, the WM packages the input (coordinates, button state) into an event message and drops it into the owning process's event queue. The application can retrieve these via the custom libc UI functions.
+
+## Userland API (`libui.c`)
+
+Applications do not talk to the hardware directly. Instead, they use a library (`libui.c`) which makes specialized system calls (`SYS_GUI`).
+
+-   **Window Creation**: `ui_create_window()` asks the kernel to instantiate a new window object and returns a handle.
+-   **Drawing**: Applications can request the kernel to fill rectangles or plot pixels inside their designated window area.
+-   **Event Polling**: The UI loop inside an app continuously calls `ui_poll_event()` to respond to mouse clicks and window movement dispatched by the kernel WM.

docs/build/toolchain.md

@@ -0,0 +1,52 @@
+# Build Toolchain
+
+BoredOS is built cross-compiled from a host system (such as macOS or Linux) to target the generic `x86_64-elf` platform.
+
+## Prerequisites
+
+To build BoredOS, you need the following tools:
+
+1.  **x86_64 ELF GCC Cross-Compiler**:
+    -   `x86_64-elf-gcc`: The C compiler targeting the freestanding overarching ELF environment.
+    -   `x86_64-elf-ld`: The linker to combine object files into the final `boredos.elf` kernel binary and userland variables.
+
+2.  **NASM**:
+    -   Required to compile the `.asm` files in `src/arch/` and `src/userland/crt0.asm`. It formats the output as `elf64` objects to be linked alongside the C code.
+
+3.  **xorriso**:
+    -   A specialized tool to create ISO 9660 filesystem images.
+    -   *Why?* `xorriso` packages the compiled kernel, Limine bootloader, and asset files (fonts, images, userland binaries) into the final bootable `boredos.iso` CD-ROM image.
+
+4.  **QEMU** (Optional but highly recommended for testing):
+    -   `qemu-system-x86_64` is used for rapid emulation and testing.
+
+## Installation (macOS)
+
+You can easily install the complete toolchain using Homebrew:
+
+```sh
+brew install x86_64-elf-binutils x86_64-elf-gcc nasm xorriso qemu
+```
+
+## Installation (Linux)
+
+Depending on your distribution, the installation commands vary. Note that some distributions may require you to build the `x86_64-elf` cross-compiler from source if it isn't available in their default repositories.
+
+### Debian / Ubuntu
+```sh
+sudo apt update
+sudo apt install build-essential bison flex libgmp3-dev libmpc-dev libmpfr-dev texinfo nasm xorriso qemu-system-x86
+```
+*(Note: You will need to build the `x86_64-elf` cross-compiler from source or find a compatible PPA, as it is not in the default Debian/Ubuntu repositories.)*
+
+### Arch Linux
+Arch Linux provides the regular tools in its standard repositories and the cross-compiler via the AUR:
+```sh
+sudo pacman -S nasm xorriso qemu-full
+yay -S x86_64-elf-gcc x86_64-elf-binutils
+```
+
+### Fedora
+```sh
+sudo dnf install make gcc gcc-c++ bison flex gmp-devel mpfr-devel libmpc-devel texinfo nasm xorriso qemu
+```

docs/build/usage.md

@@ -0,0 +1,58 @@
+# Building, Running, and Deployment
+
+BoredOS uses a single top-level `Makefile` to orchestrate the build process.
+
+## The Build Process
+
+When you run `make` in the root directory, the following stages occur automatically:
+
+1.  **Limine Setup (`limine-setup`)**:
+    If the Limine bootloader binaries are missing, the Makefile automatically clones the appropriate Limine binary release from GitHub and compiles its host utility.
+2.  **Kernel Compilation**:
+    All `.c` files in `src/core`, `src/mem`, `src/dev`, `src/sys`, `src/fs`, `src/wm`, and `src/net` are compiled into object files (`.o`) inside the `build/` directory using `x86_64-elf-gcc`.
+3.  **Kernel Assembly**:
+    All `.asm` files in `src/arch/` are assembled into object files using `nasm`.
+4.  **Kernel Linking**:
+    `x86_64-elf-ld` links the kernel object files together, instructed by the `linker.ld` script, outputting the `boredos.elf` kernel binary.
+5.  **Userland Compilation**:
+    The Makefile shifts into the `src/userland` directory, compiling the custom `libc` and generating `bin/*.elf` executable user applications.
+6.  **ISO Generation**:
+    The `iso_root` directory is staged. The kernel, Limine configuration, fonts, images, and userland applications are copied in. Finally, `xorriso` generates the `boredos.iso` bootable image.
+
+## Minimum System Requirements
+
+To run BoredOS successfully (either in emulation or on bare metal), your target machine should meet the following minimum requirements:
+
+-   **CPU**: An `x86_64` (64-bit) compatible processor.
+-   **Memory**: Approximately `~256 MB` of RAM.
+-   **Display**: A VGA-compatible display (required for the GUI Window Manager).
+-   **Networking (Optional)**: A compatible Network Interface Card (NIC) is required if you want to use the networking stack (e.g., an Intel E1000 or similar supported by the `net/nic/` drivers). Networking is not strictly required for the OS to boot or run offline applications.
+
+
+## Running in Emulation
+
+To test the generated ISO quickly without real hardware, use the QEMU emulator:
+
+```sh
+make run
+```
+
+This command invokes QEMU with specific arguments:
+-   `-m 4G`: Allocates 4 Gigabytes of RAM.
+-   `-cdrom boredos.iso`: Mounts the built OS image as a CD-ROM.
+-   `-netdev user...`: Sets up a basic NAT network interface for the OS's networking stack.
+-   `-smp 4`: Enables 4 CPU cores.
+-   `-drive file=disk.img...`: Attaches a raw disk image included in this release of BoredOS.
+
+## Running on Bare Metal
+
+> [CAUTION]
+> Running hobby operating systems on real hardware is at your own risk and may cause undefined behavior.
+
+To boot BoredOS on a physical PC:
+
+1.  Build the OS to get `boredos.iso`.
+2.  Use a flashing tool like **Balena Etcher** or `dd` to write the ISO to a USB flash drive.
+3.  Reboot your target computer, enter the BIOS/UEFI setup.
+4.  **Boot Configuration**: BoredOS supports booting on both modern **UEFI** systems and legacy **BIOS** systems natively via Limine. Ensure **Secure Boot** is disabled in your firmware settings.
+5.  Select the USB drive from the boot menu.