Tweak: Improved Documentation and README.MD

README.md

@@ -2,96 +2,83 @@
 
 <div align="center">
   <img src="boredos.svg" alt="BoredOS Logo" width="450" />
+  <p><em>A modern x86_64 hobbyist operating system built from the ground up.</em></p>
+
+  [![License: GPL v3](https://img.shields.io/badge/License-GPLv3-blue.svg)](https://www.gnu.org/licenses/gpl-3.0)
+  ![Platform: x86_64](https://img.shields.io/badge/Platform-x86_64-lightgrey)
+  ![Status: Active](https://img.shields.io/badge/Status-Active-brightgreen)
 </div>
-BoredOS is a simple x86_64 hobbyist operating system. 
+
-It features a DE (and WM), a FAT32 filesystem, customizable UI and much much more!
+---
+
+BoredOS is a functional x86_64 operating system featuring a custom Desktop Environment (DE), a dedicated Window Manager (BoredWM), and a FAT32 filesystem. It balances low-level kernel exploration with a surprisingly capable userspace.
 
 ![Screenshot](screenshot.jpg)
-*this screenshot might be outdated*
+> [!NOTE]
+> *The screenshot above may represent a previous build and is subject to change as the UI evolves.*
 
-## Features
+---
-- userspace
-- JPG image support
-- Disk manager
-- Drag and drop mouse centered UI
-- Customizable UI
-- Basic Networking Stack
-- Bored WM
-- FAT32 filesystem
-- 64-bit long mode support
-- Multiboot2 compliant
-- Text editor
-- Markdown Viewer
-- Minesweeper
-- Markdown Viewer
-- GUI Text editor
-- Paint application
-- IDT
-- Ability to run on actual x86_64 hardware
-- CLI
-- (Limited) C Compiler
 
-## Documentation
+## 🚀 Features
 
-BoredOS has comprehensive documentation available in the [`docs/`](docs/) directory covering architecture, the build system, and application development SDKs.
+### ⚙️ System Architecture
+* **64-bit Long Mode:** Fully utilizing the x86_64 architecture.
+* **Multiboot2 Compliant:** Bootable on real hardware and modern emulators.
+* **Kernel Core:** Interrupt Descriptor Table (IDT) management and a robust syscall interface.
+* **Filesystem:** Full **FAT32** support for persistent and in-memory storage.
+* **Networking:** Includes the lwIP networking stack.
 
--   **[Index / Table of Contents](docs/README.md)**
+### 📺 Graphical User Interface
--   **[Architecture Overview](docs/architecture/core.md)**
+* **BoredWM:** A custom Window Manager with drag-and-drop, mouse-centered interaction.
--   **[Building and Running](docs/build/usage.md)**
+* **Customization:** Adjustable UI to suit your aesthetic.
--   **[Application Development Guide](docs/appdev/custom_apps.md)**
+* **Media Support:** Built-in image decoding.
 
+### 🛠️ Included Applications
+* **Productivity:** GUI Text Editor calculator, Markdown Viewer, a simple browser and BoredWord.
+* **Creativity:** A Paint application.
+* **Utilities:** Terminal,Task Manager, File Explorer, Clock and a (limited) C Compiler.
+* **Games:** Minesweeper and DOOM.
 
+---
 
+## 📚 Documentation
 
+Explore the internal workings of BoredOS via our comprehensive guides in the [`docs/`](docs/) directory.
 
-###
+* 📖 **[Documentation Index](docs/README.md)** – Start here.
-###
+* 🏗️ **[Architecture Overview](docs/architecture/core.md)** – Deep dive into the kernel.
+* 🔨 **[Building and Running](docs/build/usage.md)** – Setup your build environment.
+* 🚀 **[AppDev SDK](docs/appdev/custom_apps.md)** – Build your own apps for BoredOS.
 
-<h2 align="left">Help me brew some coffee! ☕️</h2>
+---
 
-###
+## ☕ Support the Journey
+
+If you find this project interesting or helpful, consider fueling the development with a coffee!
 
-<p align="left">
-  If you enjoy this project, and like what i'm doing here, consider buying me a coffee!
-  <br><br>
 <a href="https://buymeacoffee.com/boreddevnl" target="_blank">
   <img src="https://cdn.buymeacoffee.com/buttons/v2/default-yellow.png" alt="Buy Me A Coffee" height="50" style="border-radius: 8px;" />
 </a>
-</p>
-
-###
 
 
-## This project was previously labeled as "BrewKernel"
+---
-Brewkernel was a text only very simple (and messy) project i started 3 years ago. It was my first work in OSDev and i absolutely loved it. It sadly just got too messy and i myself couldn't understand my own code anymore. About a year ago i started work on BoredOS, and pushed a *"working"* version of it a few days ago as of writing this *(Feb. 10 2026)* 
-Brewkernel has already been deprecated and will not be accepting any pull requests or fix any issues as it is now a public archive.
-Thanks to everyone who helped me with Brewkernel, even if it were just ideas, and intend to keep working on this for the forseeable future!
 
-## License
+## ⚠️ Project Disclaimer & Heritage
 
-Copyright (C) 2024-2026 boreddevnl
+**BoredOS** is the successor to **BrewKernel**, a text-only project initiated in 2023. 
 
-This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
+While BrewKernel served as the foundational learning ground for this OS, it has been officially **deprecated and archived**. It no longer receives updates, bug fixes, or pull request reviews. BoredOS represents a complete architectural reboot, applying years of lessons learned to create a cleaner, more modular, and more capable 64-bit system.
 
-NOTICE
+> [!IMPORTANT]
-------
+> Please ensure all issues, discussions, and contributions are directed to this repository. Legacy BrewKernel code is preserved for historical purposes only and is not compatible with BoredOS.
 
-This product includes software developed by Chris ("boreddevnl") as part of the BoredOS (Previously Brewkernel/BrewOS) project.
+---
 
-Copyright (C) 2024–2026 Chris / boreddevnl (previously boreddevhq)
+## ⚖️ License
 
-All source files in this repository contain copyright and license
+**Copyright (C) 2024-2026 boreddevnl**
-headers that must be preserved in redistributions and derivative works.
 
-If you distribute or modify this project (in whole or in part),
+Distributed under the **GNU General Public License v3**. See the `LICENSE` file for details. 
-you MUST:
 
-  - Retain all copyright and license headers at the top of each file.
+> [!IMPORTANT]
-  - Include this NOTICE file along with any redistributions or
+> This product includes software developed by Chris ("boreddevnl"). You must retain all copyright headers and include the original attribution in any redistributions or derivative works. See the `NOTICE` file for more details.
-    derivative works.
-  - Provide clear attribution to the original author in documentation
-    or credits where appropriate.
-
-The above attribution requirements are informational and intended to
-ensure proper credit is given. They do not alter or supersede the
-terms of the GNU General Public License (GPL), which governs this work.

docs/README.md

@@ -1,25 +1,32 @@
-# BoredOS Documentation
+<div align="center">
+  <h1>BoredOS Documentation</h1>
+  <p><em>Internal guides, architecture, and application development.</em></p>
+</div>
+
+---
 
 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
+## 📚 Table of Contents
 
 The documentation is organized into three main categories:
 
-### 1. [Architecture](architecture/)
+### 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/)
+### 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/)
+### 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

@@ -1,8 +1,13 @@
-# Creating a Custom App (Step-by-Step)
+<div align="center">
+  <h1>Creating a Custom App</h1>
+  <p><em>A step-by-step tutorial on writing a new graphical C application.</em></p>
+</div>
+
+---
 
 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
+## 📝 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`.
 
@@ -44,7 +49,7 @@ int main(void) {
 }
 ```
 
-## Step 2: Edit the Makefile
+## ⚙️ 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!
 
@@ -56,7 +61,7 @@ Now you need to tell the build system to compile `hello.c`. Fortunately, the `sr
     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
+## 📦 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.
 
@@ -69,11 +74,14 @@ The main overarching `Makefile` (in the project root) takes binaries from `src/u
     make clean && make run
     ```
 
-## Step 4: Run it inside BoredOS
+## 🚀 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.*
+> [!NOTE]
+> You can also open your app by opening the file explorer, navigating to the `bin` directory, and double-clicking the executable.
+
+---

docs/appdev/sdk_reference.md

@@ -1,8 +1,13 @@
-# Userland SDK Reference
+<div align="center">
+  <h1>Userland SDK Reference</h1>
+  <p><em>Custom libc implementations and system calls in BoredOS.</em></p>
+</div>
+
+---
 
 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 Custom libc Structure (`src/userland/libc/`)
 
 The SDK comprises a few key files containing wrappers around kernel system calls:
 
@@ -11,13 +16,14 @@ The SDK comprises a few key files containing wrappers around kernel system calls
 -   `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
+## 🖧 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) {
@@ -25,7 +31,7 @@ int sys_write(int fd, const char *buf, int len) {
 }
 ```
 
-### Notable System Calls
+### 📌 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`).
@@ -33,4 +39,7 @@ int sys_write(int fd, const char *buf, int len) {
 -   **`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.
+> [!IMPORTANT]
+> 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

@@ -1,12 +1,17 @@
-# UI API (`libui.h`)
+<div align="center">
+  <h1>UI API (<code>libui.h</code>)</h1>
+  <p><em>Interact with the BoredOS Window Manager (WM).</em></p>
+</div>
+
+---
 
 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
+## 🧠 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
+## 🪟 Example: Creating a Window
 
 First, include the library and define an event structure:
 
@@ -29,7 +34,7 @@ int main(void) {
 }
 ```
 
-## Drawing Primitives
+## 🎨 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.
 
@@ -49,7 +54,7 @@ Available rendering methods:
 -   `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
+## 🔄 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.
 
@@ -83,3 +88,5 @@ Graphical applications are event-driven. They stay alive inside a `while (1)` lo
         syscall1(SYSTEM_CMD_YIELD, 0);
     }
 ```
+
+---

docs/architecture/core.md

@@ -1,10 +1,15 @@
-# Core Architecture
+<div align="center">
+  <h1>Core Architecture</h1>
+  <p><em>Overview of BoredOS kernel layout, boot process, and userspace transition.</em></p>
+</div>
+
+---
 
 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/`)
+## 📂 Source Code Layout (`src/`)
 
 The OS heavily relies on module separation. The `src/` directory is logically split into several domains:
 
@@ -18,7 +23,7 @@ The OS heavily relies on module separation. The `src/` directory is logically sp
 - **`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
+## 🚀 Boot Process
 
 BoredOS uses **Limine** as its primary bootloader.
 
@@ -28,12 +33,19 @@ BoredOS uses **Limine** as its primary bootloader.
 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
+> [!NOTE]
+> The kernel parses memory maps dynamically, meaning it adjusts optimally to the RAM provided by the environment or emulator.
+
+## 🛡️ 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`).
+> [!IMPORTANT]
+> Programs then interact with the core kernel using system calls (`syscall.c`). Isolated processes cannot directly access hardware or kernel memory structures without faulting.
+
+---

docs/architecture/filesystem.md

@@ -1,8 +1,13 @@
-# Filesystem Architecture
+<div align="center">
+  <h1>Filesystem Architecture</h1>
+  <p><em>Virtual File System layer and FAT32 abstraction in BoredOS.</em></p>
+</div>
+
+---
 
 BoredOS implements a rudimentary but functional filesystem layer designed to support reading system assets and user applications during runtime.
 
-## Virtual File System (VFS)
+## 🗂️ 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.
 
@@ -11,18 +16,18 @@ Key VFS functionalities include:
 -   **Standard Operations**: Standardizing `open()`, `read()`, `write()`, `close()`, `seek()`, and directory listings.
 -   **Path Parsing**: Resolving absolute and relative paths.
 
-## FAT32 Implementation
+## 💾 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.
+The primary filesystem logic in `fat32.c` is currently built as a RAM-based filesystem simulation.
 
-### Booting and the RAMFS
+### 💿 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
+> [!WARNING]
-Beyond the core RAMFS used for booting, the FAT32 implementation natively supports interacting with permanent storage:
+> **Limitations:** The current `fat32.c` implementation in BoredOS is strictly a RAM-based filesystem simulation. It **does not support** reading from actual block devices (real disks). Consequently, external disk images are not recognized, and any operations requiring persistent storage are unsupported.
-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

@@ -1,8 +1,13 @@
-# Memory Management
+<div align="center">
+  <h1>Memory Management</h1>
+  <p><em>Physical and Virtual Memory coordination in x86_64 Long Mode.</em></p>
+</div>
+
+---
 
 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)
+## 🧠 Physical Memory Management (PMM)
 
 The PMM is responsible for tracking which physical RAM frames (usually 4KB each) are free and which are in use.
 
@@ -10,7 +15,10 @@ The PMM is responsible for tracking which physical RAM frames (usually 4KB each)
 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
+> [!NOTE]
+> 4KB frame sizes strike a balance between allocation speed and minimal memory fragmentation, fitting directly with the page tables.
+
+## 🗺️ 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.
 
@@ -18,6 +26,8 @@ BoredOS uses 4-level paging (PML4), a requirement for x86_64 long mode, dividing
 -   **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
+## 🏗️ 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

@@ -1,14 +1,22 @@
-# Window Manager (WM)
+<div align="center">
+  <h1>Window Manager (WM)</h1>
+  <p><em>The native graphical subsystem compositing and event routing.</em></p>
+</div>
+
+---
 
 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
+## 🖼️ 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`)
+> [!TIP]
+> The performance of the window manager heavily depends on minimizing the "dirty regions" drawn in the compositing loop rather than sweeping the whole screen.
+
+## 🪟 Window System (`wm.c`)
 
 The windowing system is built around a linked list of `Window` structures.
 
@@ -16,7 +24,7 @@ The windowing system is built around a linked list of `Window` structures.
 -   **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
+## 🖱️ Input Handling and Events
 
 The WM acts as the central hub for input routing.
 
@@ -24,10 +32,12 @@ The WM acts as the central hub for input routing.
 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`)
+## 🔌 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.
+
+---