Most “web OS” projects are just draggable windows with local state.
I wanted to see what would happen if the browser had to obey real operating system rules.
So I built WebOS — a fully simulated operating system inside the browser with:
- A modular kernel architecture
- Queue based process management
- Round Robin CPU scheduling
- First-Fit memory allocation (with fragmentation)
- Block-based virtual disk
- A Unix-inspired inode file system
- Strict Kernel → Store → UI control flow
Built using React, Vanilla JavaScript, Zustand, GSAP, and react-rnd.
This isn’t just a UI skin.
It’s a constraint-driven system model running entirely inside a browser runtime.
What It Looks Like
- Multiple apps running simultaneously
- Independent PIDs
- Per-process CPU and memory tracking
The UI reflects system state.
It never invents it.
System Architecture: Kernel → Store → UI
Most web apps follow this pattern:
- UI → State → Render
WebOS enforces:
- Kernel → Store → UI
The UI has zero authority over system resources.
1. The Kernel (Vanilla JavaScript)
The kernel is composed of independent subsystems:
- ProcessManager
- MemoryManager
- Scheduler
- FileSystem
- StorageSystem
All resource arbitration happens here.
The UI cannot allocate memory
The UI cannot spawn processes
The UI cannot write to disk
Everything goes through the kernel first.
2. The State Bridge (Zustand)
Zustand acts as an authoritative synchronization layer between the kernel and React.
When launching an app:
- UI triggers
createApp() - Kernel validates memory + CPU availability
- PID is allocated
- Memory block assigned
- Scheduler registers process
- Store syncs confirmed state
- React renders
If allocation fails, nothing renders.
The UI reacts to system state — it does not create it.
Process Management
The ProcessManager:
- Allocates PIDs
- Tracks process states (
ready,running,waiting) - Coordinates with memory + scheduler
- Ensures proper cleanup on termination
A process cannot exist without memory
It cannot execute without CPU time
Subsystem coordination is strictly enforced.
Round Robin CPU Scheduling
The Scheduler implements:
- Fixed time quanta
- Context switching
- CPU usage tracking
- Usage decay when idle
- Overload protection
If total CPU usage approaches a defined threshold, the kernel throws CPU_OVERLOAD and rejects new processes.
System stability is enforced at the kernel level.
Memory Management (First-Fit + Fragmentation)
The MemoryManager:
- Uses First-Fit allocation
- Treats memory as contiguous blocks
- Merges only adjacent free segments
- Simulates external fragmentation
You can create real “Swiss cheese” memory states.
Even if total free memory is technically sufficient, a process may fail if no contiguous block is large enough.
This introduces realistic allocation constraints inside a browser environment that normally hides them.
Block-Based Storage System
Below the file system sits a simulated disk:
- Fixed-size blocks
- Explicit allocation + deallocation
- No awareness of filenames
- No awareness of directories
The disk only understands raw blocks.
All higher-level structure is built above it.
The Inode-Based File System (Core Highlight)
Instead of storing files as simple path-based objects, WebOS implements a Unix-inspired inode model.
Identity ≠ Path
Each file has:
- A unique inode ID
- Logical size
- File type
- A list of allocated disk blocks
Directories do not store file data.
They store: name → inodeId
This creates three distinct layers:
- Namespace (directory structure)
- Identity (inode)
- Physical storage (disk blocks)
--
What This Enables
Because identity is decoupled from path:
- Renaming a file does not change its inode
- Moving a file across directories does not reallocate storage
- Recursive directory deletion is deterministic
- Disk exhaustion properly blocks file growth
- Directory relinking simulates Unix-style behavior
The StorageSystem manages raw blocks.
The FileSystem manages structure and identity.
The Kernel enforces constraints.
Modeling this inside JavaScript required extremely clean abstraction boundaries.
Windowing System
The UI layer includes:
- App registry (name → component mapping)
- Generic
<AppWindow />wrapper - Drag/resize via
react-rnd - GSAP-driven transitions
- Centralized z-index + focus handling
Apps remain isolated.
OS behavior remains centralized.
Error Simulation & System Resilience
WebOS enforces realistic failure cases such as:
OUT_OF_MEMORYCPU_OVERLOADOUT_OF_STORAGE- File system related errors
Errors originate in the kernel and propagate upward.
The UI reacts — it never simulates failure independently.
This preserves architectural integrity.
What This Project Changed for Me
The hardest part wasn’t building UI.
It was maintaining invariant rules across independent subsystems:
- Memory consistency
- Scheduler fairness
- File system integrity
- Correct resource cleanup
If one invariant breaks, the illusion collapses.
It blurred the line between frontend engineering and systems design.
What’s Next
- Terminal emulator
- App installer system
- Access control simulation
- Expanded kernel APIs
- UI overhaul after feature freeze
🔗 Links
GitHub:
Mukund149
/
Web-Based_Operating-System
Simulating a real OS in the browser
🧠 WebOS - Simulated Operating System in the Browser
WebOS is a full operating system simulation implemented entirely in the browser It models fundamental OS subsystems — process management, memory allocation, CPU scheduling, file systems, and storage — built using React, Zustand, GSAP, and a custom kernel architecture The architecture models core OS principles such as:
- Round Robin scheduling
- First-Fit memory allocation
- Fragmentation handling
- Block-based disk storage
- Inode-based hierarchical file system traversal
- Kernel-led resource arbitration
All system interactions occur through a kernel-first control flow, ensuring strict separation of the computational model and UI rendering.
🏗️ System Architecture
This project is architected into three distinct layers to mimic real-world OS design. The Zustand Store acts as an "Authoritative Cache," synchronizing the high-speed UI with the low-level Kernel logic.
- WebOS is built on a Kernel → Store → UI pipeline.
- The UI is NEVER allowed to guess system state.
- Everything goes…
Top comments (0)