Quin OS 2: Architecture, Implementation, and Empirical Evaluation of a Freestanding 64-Bit Operating System

1. Introduction & Five-Year Evolutionary Timeline (2021–2026)

Operating system research within Inbora Studio began in mid-2021 with the creation of XuNet OS, an exploratory 32-bit x86 system. Over the subsequent five years, this foundation was completely re-architected to realize a resilient, isolated 64-bit operating system capable of native graphic composition, high-throughput network communication, and self-hosted application compilation.

1.1 The 32-Bit Genesis: XuNet OS (2021)

The predecessor project, XuNet OS, focused on early bare-metal primitives: executing the 16-bit real-mode to 32-bit protected-mode transition, programming the 8259 Programmable Interrupt Controller (PIC) to remap IRQs 0–15 to interrupt vectors 0x20–0x2F, reading FAT12 floppy structures, and issuing BIOS INT 10h calls to initialize 640×480 VESA VBE linear framebuffers. While pedagogically successful, XuNet OS revealed inherent limitations: lack of hardware-enforced memory isolation, 32-bit physical addressing boundaries (capped at 4 GB without PAE), and an inability to scale across modern multi-core x86_64 architectures.

1.2 Chronological Research & Implementation Matrix

The progression of the codebase across the five-year continuum is documented below:

• 2021 — Year 1: XuNet OS Baseline
  32-Bit Protected Mode, Interrupt Handlers, and FAT12
  Constructed custom two-stage bootloader; established GDT segments (Ring-0 Code/Data); trapped CPU exceptions (0–31); developed basic PS/2 keyboard scancode decoders and a text-mode shell. Explored early graphic primitives using VESA VBE linear framebuffers.
• 2022 — Year 2: The 64-Bit Long Mode Transition
  Architecture Reset, Multiboot2, and 4-Level Paging
  Initiated clean-slate 64-bit redesign (Quin OS 1). Replaced custom bootloader with GRUB2 Multiboot 1 & 2 compliance in kernel/arch/x86_64/boot.asm. Implemented initial identity page tables using 2 MB huge pages, engaged Long Mode via IA32_EFER.LME, established the Higher-Half Direct Map (HHDM) starting at 0xFFFF800000000000, and constructed a 256-gate Interrupt Descriptor Table (IDT).
• 2023 — Year 3: Memory Virtualization & Multiprocessing
  Buddy Allocator, Copy-on-Write, and SMP Wakeup
  Authored physical frame allocator in pmm.c operating an order 0–10 buddy hierarchy. Engineered the 4-level Virtual Memory Manager (vmm.c) supporting demand paging, 2 MB huge page splitting, and Copy-on-Write (CoW) address space cloning for sys_fork(). Implemented ACPI RSDP/MADT table parsing, firing INIT-SIPI-SIPI sequences through the Local APIC to awaken Application Processors via a 16-bit real-mode trampoline at physical 0x8000.
• 2024 — Year 4: Graphics Engine & Persistent Storage
  QDS Double-Buffering, QWM Compositor, and Ext2
  Breakthrough in desktop graphics: developed the double-buffered Quin Display Server (QDS) and the integer-only Quin Anti-Aliased Engine (QAA). Developed the floating Quin Window Manager (QWM) supporting 32 concurrent windows with 7-pixel hit-test resizing and live snapping. Brought up the VirtIO-GPU modern PCI driver supporting 2560×1440 resolution. Developed the Ext2 read/write driver on VirtIO-Blk with raw superblock preservation and hardware disk safety guards.
• 2025 — Year 5: In-Tree Network Stack, Audio & Userspace Groundwork
  RFC 793 TCP Engine, AC97 DMA, and musl libc Integration
  Authored a complete RFC 793 TCP/IP stack from bare metal in pure C (sliding window, Jacobson/Karels dynamic RTO estimation). Integrated DHCP, DNS, HTTP client with gzip decoding (miniz), and SNTP clock sync (ntp.c). Developed Intel 82801AA AC97 audio driver with DMA circular buffers. Cross-compiled musl libc 1.2.4, implemented ELF64 loader with SysV AMD64 ABI stack frames, and enabled Ring-3 execution.
• 2026 — Present: Quin OS 2 Isolation & Rich Ecosystem
  POSIX Syscall Expansion, Ported Engines, and Self-Hosting
  Expanded POSIX syscall matrix to 60+ entries. Ported litehtml box-model layout with QuickJS-ng ES2020 JavaScript engine for live web browsing; ported MPEG-1/MP2 video player, Chipmunk2D physics sandbox, and Stockfish chess engine. Developed the QuinDev IDE featuring an in-tree Tiny C Compiler (TCC), enabling native C compilation directly inside Quin OS. Initiated architectural migration of QWM into an isolated privileged userspace server.

1.3 Architectural Tenets

The development methodology enforces three strict engineering rules:

• Freestanding Ring-0 Execution: The kernel binary links zero third-party C runtime libraries. String manipulation, memory barriers, hashing routines (SHA-256), and cryptographic LFSRs are implemented directly within the source tree.
• Honest Missing Features: Rather than providing dummy function returns that silently fail later in user-space, unimplemented subsystems return explicit error codes (e.g. -ENOSYS) or are omitted until fully functional.
• Headless Visual Verification: Window-manager layout, clipping logic, and raster operations are verified headlessly through automated QEMU monitor memory screen dumping (screendump), ensuring render state matches internal compositor buffers.

2. Kernel Bootstrapping & Machine Initialization

2.1 Multiboot Handover & 64-Bit Transition (`boot.asm`)

Execution initiates in 32-bit protected mode when GRUB2 transfers control to the entry point defined in kernel/arch/x86_64/boot.asm. The binary embeds both Multiboot 1 and Multiboot 2 header tags within the first 32 KB:

; Multiboot 1 Header
MULTIBOOT1_MAGIC     equ 0x1BADB002
MULTIBOOT1_FLAGS     equ 0x00000007  ; PAGE_ALIGN | MEM_INFO | VIDEO_MODE
MULTIBOOT1_CHECKSUM  equ -(MULTIBOOT1_MAGIC + MULTIBOOT1_FLAGS)

; Multiboot 2 Header (Tag Type 5: Request 1920x1080x32 Linear Framebuffer)
MULTIBOOT2_MAGIC     equ 0xE85250D6
MULTIBOOT2_ARCH_X86  equ 0

Prior to entering Long Mode, boot.asm executes CPUID checks verifying that the processor supports 64-bit execution (bit 29 of EDX from function 0x80000001). Paging is bootstrapped by identity mapping the lowest 1 GB of physical memory using 2 MB huge pages:

1. boot_pml4[0] references boot_pdpt with flags 0x03 (Present | Writable).
2. boot_pdpt[0] references boot_pd.
3. boot_pd initializes 512 entries mapping physical addresses 0x00000000 through 0x3FFFFFFF using flags 0x83 (Present | Writable | Huge Page 2MB).
4. boot_pml4[256] is initialized pointing to boot_pdpt, mapping the Higher-Half Direct Map (HHDM) starting at virtual address 0xFFFF800000000000.

Virtual Address Space Layout:
0x0000000000000000 - 0x00007FFFFFFFFFFF  [Lower Half: 128 TB Ring-3 Userspace]
  ├── 0x0000000000400000                 : ELF64 Image Base (Randomized via ASLR)
  ├── 0x0000500000000000                 : Dynamic mmap Base (Grows Upwards)
  └── 0x00007FFFFFFFF000                 : Userspace Process Stack Top (16 MB)

0xFFFF800000000000 - 0xFFFFFFFFFFFFFFFF  [Higher Half: 128 TB Ring-0 Kernel Space]
  ├── 0xFFFF800000000000                 : Higher-Half Direct Map (HHDM) — All Physical RAM
  ├── 0xFFFF800000100000                 : Kernel ELF Image (Physical 1 MB)
  ├── Post-Kernel End                    : PMM Bitmap & Frame Metadata Tables
  └── Post-Bitmap                        : Kernel Heap (kmalloc Slab Pools)
        

To switch execution modes:

; Load CR3 with physical address of PML4
mov eax, boot_pml4
mov cr3, eax

; Enable Physical Address Extension (PAE) in CR4
mov eax, cr4
or  eax, 1 << 5
mov cr4, eax

; Enable Long Mode (LME) in IA32_EFER MSR (0xC0000080)
mov ecx, 0xC0000080
rdmsr
or  eax, 1 << 8
wrmsr

; Engage Paging (PG) and Protection (PE) in CR0
mov eax, cr0
or  eax, (1 << 31) | (1 << 0)
mov cr0, eax

; Far jump into 64-bit code segment
jmp 0x08:long_mode_entry

2.2 The Deterministic Kernel Initialization Sequence (`main.c`)

Upon landing in 64-bit mode, kernel_main() executes a deterministic 12-stage initialization sequence:

• serial_init(): Configures UART 16550 COM1 at I/O port 0x3F8 (115200 baud, 8N1).
• stack_canary_init(): Seeds __stack_chk_guard with entropy from rdtsc and PIT jitter.
• pmm_init(): Iterates Multiboot memory entries, registering physical frames into the buddy allocator.
• vmm_init(): Builds runtime 4-level page tables, unmapping physical page 0 to catch NULL dereferences.
• idt_init(): Populates 256 gates with interrupt service routines; remaps PIC to vectors 0x20–0x2F.
• gdt_init(): Constructs GDT with 64-bit kernel/user segments and Task State Segment (TSS) for RSP0 stack switching.
• scheduler_init(): Programs PIT Channel 0 to 100 Hz (Mode 2) and initializes per-CPU run-queues.
• smp_init(): Parses ACPI MADT tables and broadcasts INIT-SIPI-SIPI to awaken Application Processors.
• vfs_init(): Initializes USTAR initrd, mounts devfs (/dev), procfs (/proc), tmpfs (/tmp), and shmfs (/dev/shm).
• virtio_pci_scan(): Negotiates VirtIO-GPU, VirtIO-Net, VirtIO-Blk, and VirtIO-Input modern PCI devices.
• net_stack_init(): Launches background network polling thread, initiates DHCP lease discovery, and queries NTP time servers.
• init_qds() & init_qwm(): Allocates double back-buffer and enters the non-returning desktop compositor event loop.

3. Memory Management Subsystem

3.1 Physical Memory Manager — Buddy Allocator (`pmm.c`)

Physical RAM is organized into orders 0 through 10, representing power-of-two multiples of 4 KB pages:

The buddy index of a frame $F$ at order $O$ is determined by bitwise XOR:

#define BUDDY_FRAME(f, order) ((f) ^ (1ULL << (order)))

Free blocks are tracked using a circular doubly-linked descriptor embedded directly into the first page of each unallocated block:

typedef struct free_block {
    struct free_block *next;
    struct free_block *prev;
    uint32_t magic;      /* Guarded by FREE_BLOCK_MAGIC = 0x12345678U */
    uint8_t  order;
} free_block_t;

3.2 Virtual Memory Manager & Copy-on-Write (`vmm.c`)

The VMM coordinates the AMD64 4-level paging structures. Addresses are broken down into table indices via shifting and masking:

#define PML4_IDX(virt) (((virt) >> 39) & 0x1FFUL)
#define PDPT_IDX(virt) (((virt) >> 30) & 0x1FFUL)
#define PD_IDX(virt)   (((virt) >> 21) & 0x1FFUL)
#define PT_IDX(virt)   (((virt) >> 12) & 0x1FFUL)

Copy-on-Write Resolution Sequence: When a process executes sys_fork(), the child receives a duplicate PML4. Writable page table entries in user space are marked read-only and flagged with bit 9 (PTE_COW = 1ULL << 9), while incrementing s_refcounts[frame]. When either process writes to a CoW page:

1. The processor generates a Page Fault (Exception Vector 0xE) with error code bit 1 set (Write violation).
2. vmm_page_fault_handler() extracts the faulting address from the CR2 register and walks the active PML4.
3. If PTE_COW is active and s_refcounts[frame] > 1:
   • Allocates a fresh 4 KB physical frame via pmm_alloc_frame().
   • Performs memcpy(PHYS_TO_VIRT(new_frame), PHYS_TO_VIRT(old_frame), 4096).
   • Updates the faulting process's page table entry to point to new_frame with PTE_WRITABLE set and PTE_COW cleared.
   • Decrements s_refcounts[old_frame] and issues invlpg to invalidate the local TLB entry.
4. If s_refcounts[frame] == 1, the process is the sole remaining owner: the handler clears PTE_COW, enables PTE_WRITABLE, and resumes execution without re-allocating.

3.3 Kernel Slab Allocator (`heap.c`)

Dynamic kernel heap allocations (kmalloc/kfree) are served by 8 pre-allocated Slab cache pools:

static const size_t SLAB_SIZES[8] = {32, 64, 128, 256, 512, 1024, 2048, 4096};

Each slab page is indexed by an external metadata array (s_page_meta) consuming 1 byte per physical frame. Allocations exceeding 4096 bytes automatically round up to the nearest power-of-two order and allocate directly from the PMM with META_BUDDY_FLAG (0x80).

4. Preemptive Multi-Core SMP Scheduling

4.1 Application Processor Startup & Per-CPU State

Quin OS parses ACPI tables to identify available processor cores via the Multiple APIC Description Table (MADT). To awaken secondary cores (Application Processors):

1. The Bootstrap Processor (BSP) copies the real-mode trampoline from smp_trampoline.asm to physical address 0x8000.
2. The BSP dispatches an INIT Inter-Processor Interrupt (IPI) via the Local APIC Interrupt Command Register (ICR).
3. Following a 10 ms delay, the BSP issues two Startup IPIs (SIPI) specifying vector 0x08 (target address 0x8000).
4. Each AP transitions through protected mode to Long Mode, loads a unique TSS and GDT, configures its own Local APIC timer, and registers into the global scheduler table g_per_cpu[SMP_MAX_CPUS].

4.2 Slicing Mechanics: PIT Mode 2 vs Mode 3

Preemptive scheduling relies on dual timing sources:

• PIT Channel 0: Configured in Mode 2 (Rate Generator, command byte 0x34) running at 100 Hz ($10 \text{ ms}$ quantum). In earlier revisions, Mode 3 (Square Wave, 0x36) was utilized, but under hypervisor acceleration (QEMU TCG), each square-wave cycle generated two rising-edge interrupts, causing the kernel clock to drift at $2.0\times$ wall-clock speed. Migrating to Mode 2 eliminated clock acceleration.
• Local APIC Periodic Timers: Programmed at 1 kHz ($1 \text{ ms}$) on each individual core to handle thread sleeps, sub-quantum timekeeping, and TCP retransmission timeouts without cross-core bus contention.

4.3 The Cross-Core Work-Stealing Race (`BUG-080`)

To permanently resolve this race condition, spinlock release was migrated directly into the assembly implementation of switch_context in kernel/arch/x86_64/switch.asm:

switch_context:
    ; System V AMD64 ABI: RDI = prev, RSI = next, RDX = runq_lock
    push rbx
    push rbp
    push r12
    push r13
    push r14
    push r15

    ; 1. Store updated stack pointer into prev->rsp (offset 8)
    mov [rdi + 8], rsp

    ; 2. Switch to incoming thread's stack
    mov rsp, [rsi + 8]

    ; 3. ATOMIC RELEASE: Release runq_lock ONLY after we are provably
    ;    off prev's stack and prev->rsp is coherent!
    mov dword [rdx], 0

    ; 4. Restore incoming callee-saved registers
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    pop rbx
    ret

5. System Calls, Kernel Security & SysV AMD64 ABI

5.1 Fast System Call Entry & CVE-2012-0217 Mitigation

System calls enter the kernel via the CPU SYSCALL instruction. During boot, Model-Specific Registers are initialized:

• IA32_LSTAR (0xC0000082): Configured with the linear address of syscall_entry.
• IA32_STAR (0xC0000081): Encodes kernel and user CS/SS segment selectors.
• IA32_FMASK (0xC0000084): Configured to mask IF, DF, and the Alignment Check (AC) bit.

syscall_entry:
    swapgs                      ; Switch to per-CPU scratch
    mov [gs:8], rsp             ; Preserve user RSP
    mov rsp, [gs:0]             ; Load kernel RSP0 from TSS

    push qword [gs:8]           ; Push user RSP
    push rax                    ; Preserve GPRs
    push rbx
    push rcx                    ; User return RIP
    push rdx
    push rsi
    push rdi
    push rbp
    push r8
    push r9
    push r10
    push r11                    ; User RFLAGS
    push r12
    push r13
    push r14
    push r15

    mov  rdi, rsp               ; Pass frame pointer to C dispatcher
    call syscall_dispatch

5.2 Galois LFSR Address Space Layout Randomization (`aslr.c`)

To prevent return-oriented programming (ROP) exploits in Ring-3 binaries, Quin OS implements Address Space Layout Randomization (ASLR) using a 32-bit maximal-length Galois Linear Feedback Shift Register (LFSR). The generator polynomial is:

P(x) = x³² + x²² + x² + x + 1   (Tap Mask: 0xB4BCD35CUL)

The LFSR is seeded during early boot from hardware rdtsc jitter and PIT timing counters. Generated address slides are rounded to 2 MB boundaries to preserve shared-library relative segment offsets across elf_execve() invocations.

6. Graphics Architecture & Window Compositor

6.1 Double-Buffered Composition Engine (`qds.c`)

The Quin Display Server maintains two full-resolution ARGB32 surfaces: a front buffer mapped directly to physical display MMIO (VirtIO-GPU or Bochs BGA) and a heap-allocated back buffer. To maximize throughput on high-resolution displays (2560×1440 at 32 bpp, requiring 14.7 MB per frame), QDS implements dirty damage rectangle tracking:

typedef struct {
    uint32_t *back;
    uint32_t *front;
    uint32_t  width, height;
    /* Dirty damage bounding box */
    uint32_t  dmg_x, dmg_y;
    uint32_t  dmg_x2, dmg_y2;
    int       dmg_valid;
} qds_state_t;

When windows are dragged or content reflows, only the dirty bounding region is transferred across the PCI bus via VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D and VIRTIO_GPU_CMD_RESOURCE_FLUSH, reducing bus transfer volume by up to 88% during typical desktop use.

6.2 Anti-Aliasing & Acrylic Blur (`qaa.c`)

The Quin Anti-Aliased Engine (QAA) provides sub-pixel font rendering and geometric drawing without floating-point or SSE instructions:

• Coverage-Based Antialiasing: Computes corner alpha coverage for rounded rectangles using fast integer square-root approximations.
• Acrylic Frosted Glass: Implements a multi-pass horizontal and vertical box blur over cached window backdrops, enabling translucent blur effects for titlebars and the system dock.

6.3 Floating Window Manager (`qwm.c`)

QWM is an 8,300-line compositor managing window Z-ordering, PS/2 mouse coordinate mapping, and desktop chrome:

• Maintains up to 32 concurrent floating windows with integer Z-order arrays (z_raise(), z_remove()).
• Features 7-pixel hit-test boundary zones for responsive bidirectional edge resizing.
• Renders macOS-style traffic-light window controls (Close: #FF5F56, Minimize: #FFBD2E, Maximize: #27C93F) with hover interpolation.
• Renders a floating bottom dock displaying pinned icons and a live uptime clock driven directly by scheduler_get_ticks() at 100 Hz.
• Supports dynamic JSON theme hot-reloading from /theme.json, enabling real-time accent color switches.

7. In-Tree Bare-Metal RFC 793 TCP Engine

Quin OS incorporates an independent, freestanding Transmission Control Protocol implementation (drivers/net/tcp.c) designed to RFC 793 specifications without external networking libraries:

7.1 State Machine & Sliding Window Flow Control

The stack implements the complete TCP finite state machine: CLOSED, SYN_SENT, SYN_RECEIVED, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT, CLOSING, LAST_ACK, and TIME_WAIT. Connections negotiate Maximum Segment Size (MSS, default 1460 bytes) and Window Scale options during the 3-way handshake.

7.2 Jacobson/Karels RTO Estimation & Fast Retransmit

Dynamic Retransmission Timeouts (RTO) are calculated by tracking smoothed round-trip time ($SRTT$) and round-trip variance ($RTTVAR$):

RTTVAR ← (1 - β) × RTTVAR + β × |SRTT - R'|
SRTT ← (1 - α) × SRTT + α × R'
RTO ← SRTT + max(G, 4 × RTTVAR)

Where $\alpha = 1/8$, $\beta = 1/4$, and RTO is bounded between $200 \text{ ms}$ and $15 \text{ s}$. The stack triggers fast retransmission immediately upon receiving three duplicate acknowledgments (dup-ACKs), bypassing timer expiration.

7.3 Supporting Protocols & Time Synchronization

The network subsystem is completed by:

• Ethernet & ARP: Dynamic ARP table resolution with automatic entry aging.
• IPv4 & ICMP: RFC 791 packet validation, header checksum verification, and ping echo response.
• DHCP: Broadcast lease negotiation acquiring IP, netmask, default gateway, and DNS servers.
• DNS: UDP-based A-record query parser.
• SNTP Client (`ntp.c`): RFC 4330 client querying global NTP pools, computing four-timestamp clock offsets to correct local RTC drift.
• HTTP & TLS: HTTP/1.1 client supporting gzip Accept-Encoding decompression via miniz and TLS 1.3 encryption via ported mbedtls.

8. Storage Architecture & Filesystem Drivers

8.1 Virtual File System Architecture (`vfs.c`)

The Virtual File System routes operations through a 16-node prefix mount table:

• /: Read-only USTAR Ramdisk loaded from GRUB2 initrd.
• /ext2: Persistent read/write Second Extended Filesystem backed by VirtIO-Blk or AHCI SATA drives.
• /dev: Device nodes including /dev/fb0 (framebuffer), /dev/tty, /dev/urandom (ChaCha20), /dev/null, /dev/zero.
• /proc: Dynamic kernel diagnostics (/proc/meminfo, /proc/self/maps, /proc/net).
• /tmp: High-speed volatile memory-backed tmpfs.
• /dev/shm: Shared-memory IPC filesystem for zero-copy Ring-3 window surfaces.

8.2 Ext2 Implementation & Hardware Safety Gates (`ext2.c`)

The Ext2 driver supports block sizes of 1024, 2048, and 4096 bytes, direct, indirect, and doubly-indirect block addressing, and directory tree traversals.

8.3 Hardware Driver Matrix

9. Userspace Architecture & musl libc 1.2.4

9.1 System V AMD64 ABI Stack Initialization (`elf.c`)

The ELF64 loader maps PT_LOAD segments into per-process address spaces. Before transferring execution to user space via sysretq or iretq, the kernel constructs the System V AMD64 ABI stack frame:

Higher Addresses
  [ strings: environment strings, argument strings ]
  [ 16-byte random seed for ChaCha20 stack canary ]
  [ auxv: AT_PHDR, AT_PHENT, AT_PHNUM, AT_PAGESZ=4096, AT_ENTRY, AT_RANDOM, AT_NULL ]
  [ envp: envp[n]=NULL, ..., envp[0] ]
  [ argv: argv[argc]=NULL, ..., argv[0] ]
  [ argc: 64-bit integer ] <-- User RSP (16-byte aligned)
Lower Addresses

9.2 Ported Applications & Native Engines

Through its POSIX syscall compatibility and static linking against musl libc, Quin OS 2 hosts a diverse set of applications:

• Web Browser (`r3_browser`): Integrates litehtml for HTML5 box-model rendering and float/table layout, wired to QuickJS-ng for ES2020 JavaScript execution and DOM manipulation.
• Video Player (`r3_video`): Decodes MPEG-1 video streams and MP2 audio streams via pl_mpeg, synchronizing frame presentation with AC97 audio output at 30 FPS.
• Physics Engine (`r3_physics`): Embeds Chipmunk2D rigid-body simulation with collision detection, reacting dynamically when window titlebars are jostled.
• Gaming & Emulation: Ported Stockfish chess engine with graphical board, classic DOOM (doomgeneric), Quake 1, and hardware emulators for NES, Game Boy, and Sega Genesis.
• Self-Hosting IDE (`r3_ide`): Full-featured development environment with syntax highlighting and the Tiny C Compiler (TCC), allowing developers to write and compile C software directly within Quin OS.

10. Comparative Architectural Analysis

10.1 Quin OS 2 vs. Linux Kernel (v6.x)

10.2 Quin OS 2 vs. TempleOS (Terry A. Davis)

11. Performance Benchmarking & Optimization Techniques

11.1 Empirical Measurements

11.2 Key Architectural Optimizations

Three low-level design patterns account for Quin OS's responsiveness and low memory footprint:

• Pre-Baked Zero-Decode UI Assets: Runtime image decoding on application launch introduces substantial CPU stalls. Quin OS 2 compiles pre-baked 0xAARRGGBB raw pixel arrays directly into the kernel for all preview cards, icons, and theme chrome widgets. This enables instantaneous rendering without memory allocation or decoding latency.
• Integer-Only Rasterization: The graphics subsystem avoids floating-point operations in Ring 0, avoiding FXSAVE/FXRSTOR FPU state save/restore overhead during compositor redraw cycles.
• Dirty Damage Clipping: The display server limits blit transfers to modified bounding rectangles, avoiding continuous 14.7 MB whole-frame transfers at 2560×1440 resolution.

12. Engineering Roadmap & Future Research

Active engineering on Quin OS 2 is structured across five progressive phases:

• Phase 1: Foundation (Completed): Buddy allocator PMM, 4-level paging VMM, ACPI MADT SMP scheduler, and POSIX syscall interface.
• Phase 2: Persistent Storage & Networking (Completed): Ext2 read/write on VirtIO-Blk, in-tree RFC 793 TCP/IP stack, double-buffered QDS compositor, and QWM window manager.
• Phase 3: Userspace Isolation & Ported Suite (Completed): musl libc 1.2.4 integration, ELF64 loader with ASLR, litehtml+QuickJS web browser, MPEG-1 video player, Chipmunk2D physics, and in-tree TCC compiler.
• Phase 4: Privileged Compositor Server (In Progress): Migrating QWM from Ring-0 into an isolated userspace server process (/sbin/qwm.elf) communicating over /dev/shm shared-memory surfaces via QuinIPC.
• Phase 5: Dynamic Linking & Vectorization (Future): Implementing ld-quin.so dynamic ELF linker and SIMD/AVX2 acceleration for compositor rasterization.

13. Research Attribution & BibTeX Citation

To cite this research in academic publications, technical reports, or comparative operating system literature, please use the following BibTeX entry:

Official Project Repositories

• Quin OS 64-Bit Repository: https://github.com/InboraStudio/Quin-1-OS
• Cloud Quin OS 2 Repository: https://github.com/InboraStudio/Cloud_quin_os2
• XuNet OS 32-Bit Prototype: https://inborastudio.github.io/XuNetOS
• Inbora Studio Portal: https://inborastudio.github.io/