Architectural Specification for a Browser-Native Desktop Emulation Environment

Full report

On this page

1. Executive Summary

The present analysis details the conceptual and technical architecture required to engineer a self-contained, browser-based desktop operating environment. The fundamental objective is to deliver a digital archive that authentically emulates an early-2000s computing paradigm, encapsulating a variety of specialized analytical applications: a Windows-era desktop, an Internet Explorer-style historical website viewer, a Research Explorer, a read-only cyber/research console, a Cognitive Atlas visualization application, an Ethics Workbench, a Book Archive, and System Properties. This environment must function entirely on the client side, strictly adhering to a highly constrained technological mandate: utilizing exclusively vanilla JavaScript, HTML, CSS, and PHP. The architecture must explicitly prohibit third-party JavaScript libraries, UI frameworks, npm runtime dependencies, CDN assets, external APIs, and remote analytics. The system must operate as a conventional web application hosted from a single origin while progressively degrading to accommodate mobile devices and constrained browser environments. Crucially, the engineering design must guarantee the absolute integrity of canonical archive records; the emulation layer may derive and manipulate application UI state, but source provenance must remain immutable. Furthermore, the visual emulation of historical software must not compromise modern accessibility standards; semantic truthfulness and WAI-ARIA compliance must be maintained throughout the environment1. The core engineering challenge lies in synthesizing a robust operating system (OS) mental model—encompassing window management, process lifecycles, virtual file systems, inter-process communication, and hardware interrupts—within the single-threaded, document-centric context of a modern web browser4. The recommended architecture centers on a centralized desktop kernel and reactive state store, augmented by an event-driven system bus and a virtual file system with copy-on-write semantics. This exhaustive specification provides the implementation-independent blueprint necessary for an engineering team to execute the architecture within the established constraints.

2. Mental Model for the Emulated OS

To construct a convincing, highly cohesive desktop environment within a web browser, the architectural mental model must meticulously map traditional operating system primitives to their web-native equivalents4. The browser tab serves as the hardware substrate, the execution environment, and the hardware virtualization layer simultaneously. The intention is to transcend the paradigm of interconnected web modals and instead present a deterministic state machine where the user interface is purely a projection of the underlying OS state.

The desktop session encapsulates the entire operating context for a single user visit. It maintains the registry of active processes, the visual layout of desktop shortcuts, the current wallpaper, and the unified configuration of the environment. The desktop session is inherently ephemeral in the JavaScript heap but is periodically serialized and written to the local storage backend to facilitate session restoration. Applications are the functional units of the environment—such as the Cognitive Atlas or the Ethics Workbench. They are defined by declarative manifests that specify their dependencies, initial window dimensions, supported file associations, and required icons. When an application is launched, it transitions into a process, which is a living instance of the application class assigned a unique Process Identifier (PID) by the kernel. Windows are the physical manifestations of processes within the Document Object Model (DOM). A single process may own one primary window and multiple child windows or modal dialogs. The taskbar entries are reactive projections of the active window list, dynamically reflecting whether a window is focused, minimized, or requesting user attention. Desktop shortcuts are metadata files stored in the VFS desktop directory, containing execution intents that the kernel resolves to specific applications.

3. Alternative Architectures and Tradeoffs

When designing the foundational architecture for the web desktop, it is necessary to evaluate multiple internal architectural patterns. Given the constraints regarding URL synchronization, navigation history, and failure isolation, three distinct architectural models were analyzed.

3.1. Architecture A: Centralized Desktop Kernel/Store

In this pattern, a single root object (the Kernel) holds a global, normalized state tree containing all active processes, window geometries, file system metadata, and configuration variables. The User Interface—including the desktop, taskbar, and application frames—is a strictly reactive projection of this central state.

• Advantages: This approach trivializes state serialization, allowing for exact session restoration. It enables seamless URL synchronization and deep-linking, as the URL can be formulated as a representation of a specific state fragment. Furthermore, managing focus and z-order is highly deterministic because a central authority calculates the global order5.
• Disadvantages: A centralized store can become a performance bottleneck if the state tree grows excessively large or if state mutations trigger unoptimized, cascading DOM reflows. It requires strict developmental discipline to ensure applications communicate state changes via system calls rather than directly mutating the DOM or global variables.

3.2. Architecture B: Application-Owned Isolated State with Message Bus

This architecture mimics a true microkernel OS. Applications are heavily isolated—potentially running within hidden iframe contexts to enforce boundary security—and manage their internal state entirely independently. The kernel is relegated to handling window framing and pointer events, while the application paints its interior. Applications communicate exclusively via an asynchronous message bus4.

• Advantages: This model offers excellent failure isolation; an unhandled exception or memory leak in the Ethics Workbench will not crash the Research Explorer or the Desktop Shell. It closely mirrors real OS architecture and scales well horizontally.
• Disadvantages: It is extremely difficult to implement synchronous URL routing, browser back/forward behavior, and deep-linking, as the global state is fragmented across isolated instances. Session restoration requires complex, multi-stage orchestration to query each application for its serialization payload. Additionally, passing complex accessibility contexts across isolation boundaries is highly inefficient in vanilla JavaScript.

3.3. Architecture C: Event-Sourced Desktop Session

This approach models the operating system as an immutable sequence of events (e.g., DesktopInitialized, WindowOpened, FileRead, WindowMoved, ProcessTerminated). The current state of the desktop is derived by continuously reducing the event log.

• Advantages: Event sourcing provides unparalleled auditing, debugging, and historical playback capabilities. It inherently supports system-wide undo/redo mechanics, which could be conceptually interesting for a digital archive.
• Disadvantages: The memory overhead is severe, as the event log grows unbounded during a long session. It is computationally expensive to continuously rebuild the state, particularly on constrained mobile devices. The complexity of implementing event sourcing without external state management libraries in vanilla JavaScript introduces significant engineering risk.

4. Recommended Internal Architecture

The Centralized Desktop Kernel/Store (Architecture A) is unequivocally recommended for this project. The primary directives of the project include exact URL synchronization (mapping standard web navigation to OS state), native browser Back/Forward integration, and comprehensive WAI-ARIA accessibility semantics. A central source of truth is mandatory to orchestrate the complex focus trapping and z-index recalculations required to meet these constraints without race conditions. The architecture is subdivided into five primary execution layers:

1. The Bootloader: A minimal script executed upon DOMContentLoaded. It initializes the local storage databases, mounts the Virtual File System, checks the URL hash for deep-link intents, and instantiates the Kernel.

2. The Kernel: The orchestration singleton. It owns the unified SystemState object and exposes a rigid API of System Calls (e.g., sys\_spawn, sys\_terminate, sys\_focus).

3. The Process Manager: Subservient to the Kernel, this module manages the lifecycle of application classes, allocating memory, injecting environment variables, and handling process suspension or termination.

4. The Window Manager: A highly optimized layout engine that listens to state changes and manipulates the DOM. It calculates z-indexes, handles drag-and-drop mechanics via high-performance requestAnimationFrame loops, and enforces accessibility boundaries (inerting background windows).

5. The Virtual File System (VFS): A unified, asynchronous API providing Unix-like path resolution. It bridges the immutable PHP backend with local IndexedDB storage to simulate a read/write environment while protecting canonical records.

This centralized approach guarantees that if a user clicks the browser's native "Back" button, the URL change triggers a deterministic state reduction in the Kernel, updating the Window Manager to immediately reflect the historical state.

5. Proposed Core Objects/Interfaces

To facilitate an implementation-independent transition to engineering, the system's core contracts are defined below using language-neutral, strongly typed pseudocode. These interfaces dictate the boundaries and responsibilities of the modules within the vanilla JavaScript environment.

TypeScript // Core System State interface ISystemState { sessionId: string; processes: Map\<string, IProcessState\>; windows: Map\<string, IWindowState\>; zOrder: string\[\]; // Array of Window IDs, bottom to top focusedWindowId: string | null; environment: { theme: 'classic' | 'high-contrast'; wallpaper: string; isMobileMode: boolean; }; }

// The Kernel Contract interface IKernel { state: ISystemState; bus: ISystemBus; vfs: IVirtualFileSystem;

// System Calls execute(appManifestId: string, args?: Record\<string, any\>): string; // Returns PID terminate(processId: string): void; requestFocus(windowId: string): void; reboot(): void; }

// Window Management Engine interface IWindowManager { createWindow(config: IWindowConfig): string; // Returns Window ID destroyWindow(windowId: string): void; updateGeometry(windowId: string, rect: IRect): void; setState(windowId: string, state: 'normal' | 'minimized' | 'maximized'): void; calculateZOrder(): void; trapFocus(windowId: string): void; }

interface IWindowConfig { processId: string; title: string; iconUrl: string; initialRect: IRect; isModal: boolean; parentWindowId?: string; // For child windows resizable: boolean; maximizable: boolean; }

// Universal Application Contract interface IApplication { processId: string;

// Lifecycle Hooks onInit(args: Record\<string, any\>): Promise\<void\>; onMount(containerElement: HTMLElement): void; onFocus(): void; onBlur(): void; onSuspend(): void; onMessage(topic: string, payload: any): void; onTerminate(): void; }

// Virtual File System overlay interface IVirtualFileSystem { // Read operations check IndexedDB first, then fallback to PHP backend readFile(path: string): Promise\<ArrayBuffer\>; readText(path: string): Promise\<string\>; readDir(path: string): Promise\<IFileStat\[\]\>;

// Write operations exclusively write to IndexedDB (copy-on-write) writeFile(path: string, data: ArrayBuffer): Promise\<void\>; deleteFile(path: string): Promise\<void\>; // Writes a tombstone record stat(path: string): Promise\<IFileStat\>;

// File Associations getAssociation(mimeType: string): string; // Returns App Manifest ID }

interface ISystemBus { subscribe(topic: string, callback: Function): string; // Returns token unsubscribe(token: string): void; publish(topic: string, payload: any): void; }

6. Window/Application Lifecycle State Machine

The lifecycle of an application and its associated window must be tightly coupled and rigorously controlled to prevent memory leaks, dangling DOM nodes, and corrupted accessibility trees. The state machine follows a strict progression from memory allocation to destruction.

Code snippet stateDiagram-v2 \[\\] \--\> Instantiated : Kernel.execute() Instantiated \--\> Initializing : process.onInit() Initializing \--\> Running : process.onMount() & Window Created Running \--\> Suspended : Window Minimized / Lost Focus Suspended \--\> Running : Window Restored / Focused Running \--\> Terminating : User closes window or Kernel.terminate() Suspended \--\> Terminating : Kernel.terminate() Terminating \--\> \[\\] : DOM unmounted, memory freed

6.1. State Transitions in Detail

1. Instantiated: The Kernel allocates a Process ID, resolves the application manifest, and constructs the application class instance. Memory is allocated, but no DOM operations occur.

2. Initializing: The kernel invokes onInit(). The application parses its launch arguments (e.g., a file path passed from the VFS to the Research Explorer), establishes database connections if necessary, and prepares its internal state. This is an asynchronous phase.

3. Running: The Window Manager creates the HTML framing (title bar, borders, resize handles). It calls onMount(container), passing a reference to the window's inner content \<div\>. The application attaches its DOM subtree. The window is placed at the top of the z-order, and onFocus() is triggered.

4. Suspended: If the window is minimized to the taskbar, or if another application gains absolute focus, the process transitions to Suspended. The Kernel invokes onBlur() or onSuspend(). The application should halt intensive rendering loops, pause animations, and reduce processing overhead.

5. Terminating: Triggered by a user closing the window, a system shutdown, or a fatal error. The Kernel invokes onTerminate(). The application is mandated to remove all event listeners attached to the SystemBus or global document, clear timers, and release memory. The Window Manager subsequently destroys the window DOM node, and the garbage collector reclaims the heap allocation.

6.2. Child Windows and Modal Dialogs

Processes may spawn child windows (e.g., an "About" dialog or a "Confirm Deletion" prompt). The Kernel maps these child windows to the parent's Process ID. If a child window is declared as isModal: true, the Window Manager initiates a blocking state. It calculates the bounds of the parent window, applies a visually semi-transparent scrim (or purely programmatic block) over the parent's interior, and traps all pointer and keyboard events exclusively within the child window until it is resolved and closed10.

7. Desktop Event Model

The interaction between the user and the emulated OS relies on translating raw, browser-native DOM events (like mousedown, mousemove, and keydown) into semantic OS events.

7.1. Pointer Capture and Window Geometry (Drag & Resize)

Standard HTML5 Drag-and-Drop is notoriously insufficient for smooth, desktop-like window manipulation. Instead, the architecture utilizes manual pointer tracking combined with high-performance rendering loops.

1. Hit Testing: The desktop container delegates all pointer events to the Window Manager. When a mousedown occurs, the manager checks the target element. If it matches a window title bar, it initiates a drag sequence. If it hits an invisible 8px-wide standard DOM element positioned at the window's edges, it initiates a resize sequence.

2. Pointer Capture: Crucially, upon mousedown, the Window Manager calls element.setPointerCapture(pointerId). This vanilla API ensures that even if the user drags their mouse rapidly and the cursor leaves the physical bounds of the title bar, the mousemove and mouseup events continue to be routed to the window manager, preventing the drag operation from abruptly dropping11.

3. Frame Synchronization: During a drag or resize, the delta coordinates are not immediately applied to the DOM. They are stored in variables. A requestAnimationFrame loop reads these variables and applies the geometric translation via CSS transform: translate(x, y) rather than modifying top and left. transform utilizes GPU compositing, avoiding synchronous layout thrashing and maintaining a smooth 60fps experience12.

7.2. Z-Order Calculation

The visual stacking of windows (z-index) must be calculated deterministically. Base z-index begins at 100 to ensure windows always appear above desktop icons and base environment layers14. When a window receives a mousedown event anywhere within its boundaries, the Kernel invokes requestFocus(windowId). The Window Manager updates the zOrder array by removing the target ID and pushing it to the end (representing the top). It then iterates through the array, applying a linearly increasing z-index to each corresponding window DOM node8.

7.3. Context Menus

Context menus simulate native right-click behavior. The desktop container listens for the contextmenu event and calls event.preventDefault() to suppress the browser's native menu. Based on the event target (e.g., a file icon, the desktop background, or a taskbar item), the Kernel dynamically constructs a list of actions. The context menu is rendered as an absolute-positioned DOM node at the clientX and clientY coordinates. A global mousedown listener is immediately attached to the document; if a click occurs outside the bounds of the context menu, the menu is instantly destroyed, mimicking standard OS behavior.

7.4. Keyboard Focus Routing

A convincing OS must handle keyboard shortcuts reliably. When a window is brought to the top of the z-order, the Window Manager programmatically calls .focus() on a designated hidden input or the primary interactive element within that window. This global focus trap ensures that shortcuts (e.g., Ctrl+F for finding text in the Book Archive, or Ctrl+S for saving in the Ethics Workbench) are routed to the active Process rather than captured by the browser window.

8. Inter-Application Messaging Model

To maintain modularity and failure isolation, applications must not hold direct memory references to one another. Interactions are facilitated through the Publish/Subscribe (Pub/Sub) System Bus4.

8.1. Pub/Sub Architecture

The SystemBus acts as the nervous system of the OS. It allows processes to subscribe to strongly typed string topics.

• System Events: Emitted autonomously by the Kernel (e.g., system:clock\_tick, system:network\_status, vfs:volume\_mounted).
• Application Events: Emitted by processes to broadcast their state changes (e.g., explorer:directory\_changed, viewer:document\_loaded).
• Intended Commands (IPC): Directives targeted at specific protocols (e.g., intent:open\_file, intent:print\_document).

8.2. File Associations and Intent Resolution

Consider a scenario where the user double-clicks a dataset in the Research Explorer.

1. The Research Explorer evaluates the action and emits a message: bus.publish('intent:open\_file', { path: '/archive/data.csv', mimeType: 'text/csv' }).

2. The Kernel, constantly listening to the intent:\* namespace, intercepts the message.

3. The Kernel queries the VFS for the File Associations table, resolving text/csv to the CognitiveAtlas application manifest.

4. The Kernel executes a new instance of the CognitiveAtlas process, passing the file path as an initialization argument.

8.3. Shell Commands

The read-only cyber/research console operates as a specialized application that interfaces directly with the Kernel via the System Bus. When a user types a command (e.g., cat /reports/confidential.txt), the console parses the input and publishes a shell intent. The Kernel resolves this by querying the VFS for the text content and publishing the result back to the console's specific PID, allowing terminal emulation without actual backend shell access.

9. URL/Deep-Link Architecture

A foundational constraint of this project is that the emulation must operate as a conventional web application. This necessitates synchronizing the multi-dimensional OS state with the one-dimensional URL string to support browser history, bookmarking, and external sharing.

9.1. Bi-Directional Synchronization Pattern

The system relies on the HTML5 History API (pushState and replaceState) to manipulate the URL without triggering page reloads. To prevent URLs from becoming excessively convoluted, the architecture synchronizes the URL exclusively to represent the state of the currently focused foreground application.

• URL Format: https://archive.example.com/\#/\[AppManifestId\]/\[App-Specific-Path\]?query=params
• Example: /\#/ResearchExplorer/mnt/archive/reports/2001\_analysis.txt

9.2. URL to State (Deep Linking)

During the Bootloader phase, the Kernel parses the URL hash. If a deep link is detected, the Kernel bypasses the standard idle desktop initialization. It automatically spawns the application specified in the hash and passes the remainder of the path as arguments, effectively deep-linking the user directly into the archived record inside the windowed environment.

9.3. State to URL (History Tracking)

When the Window Manager elevates a new window to the top of the z-order, it queries the active Process for its routing state. The Window Manager uses history.pushState(stateObject, title, newUrl) to update the address bar. The stateObject contains a minimal serialization of the Kernel's state, specifically noting the active Process ID and its internal path.

9.4. Browser Back/Forward Behavior

The Kernel attaches an event listener to the global popstate window event, which is fired when the user clicks the browser's Back or Forward buttons. When triggered, the Kernel reads the historic stateObject.

• If the state indicates a shift to a process that is currently running but suspended in the background, the Kernel simply instructs the Window Manager to raise that window's z-order and restore focus.
• If the state indicates a shift to an application that has since been terminated, the Kernel transparently re-launches the application using the historical arguments, seamlessly fulfilling the history request while maintaining the OS illusion.

10. State Persistence and Restoration

To provide a cohesive "OS" feel, the system must persist window positions, desktop icon arrangements, and user-generated configurations across browser reloads, functioning as a session restore mechanism.

10.1. The Storage Backend

Because external databases and APIs are prohibited, the architecture relies heavily on the browser's native IndexedDB API for structured, asynchronous storage of complex objects (like file blobs and session states), falling back to localStorage solely for synchronous, lightweight preferences (like the system theme).

10.2. The VFS Copy-on-Write Overlay

A hard constraint dictates that canonical archive records must never be modified by the emulation layer, yet users may attempt to rename, edit, or delete files to interact with the environment. The Virtual File System (VFS) resolves this via an overlay architecture7.

• The PHP backend serves as the Read-Only base layer (mounted at /mnt/archive).
• IndexedDB serves as a Read/Write overlay layer (mounted at /C:/Users/Guest).
• When a user attempts to edit a historical file, the VFS intercepts the write operation and saves the modified payload to IndexedDB, mapping it to the original file path.
• Subsequent read requests for that path check IndexedDB first. If the file exists in the overlay, it is returned. If not, the VFS fetches it from the PHP backend. If a file is "deleted," a tombstone record (a zero-byte file with a deletion flag) is written to the overlay. This guarantees the canonical source remains pristine while perfectly simulating full write access for the user session.

10.3. Session Serialization and Hydration

The Kernel's ISystemState must be serializable. References to live DOM nodes or function closures cannot be stored.

• Periodically (e.g., via requestIdleCallback or a debounced timer on window manipulation), the Kernel captures the current state. Transient data is stripped. Only Process IDs, Window geometries (X, Y, width, height), and essential application payloads are retained. This minimized JSON object is written to the SessionStore within IndexedDB.
• Upon a subsequent visit, the Bootloader checks IndexedDB. If a session exists, it reconstructs the state: restoring the desktop background, spawning recorded processes, and instructing the Window Manager to apply the historical geometries and Z-order exactly as they were left.

11. Failure Isolation

In a standard OS, a crashing process generates a segmentation fault and is cleanly terminated by the kernel without destabilizing the rest of the system. In a JavaScript single-page application, an unhandled exception in one module can halt the global execution thread, crashing the entire desktop.

11.1. Defensive Execution Boundaries

To mitigate catastrophic failures within a vanilla JS environment without relying on Web Workers (which lack the necessary synchronous DOM access for UI rendering):

1. Process Try/Catch Wrappers: All application lifecycle hooks (onInit, onMount, onMessage) invoked by the Kernel are heavily guarded by strict try/catch blocks.

2. Event Bus Safeguards: The SystemBus executor wraps all subscriber callbacks in try/catch blocks. If the Ethics Workbench's listener throws an error, the bus catches the exception, logs a "Process Crash" event to the cyber console, and continues delivering the message to remaining subscribers4.

3. Graceful Degradation and Termination: If an application throws a fatal error, the Kernel catches the exception and forces a terminate() sequence on the offending Process ID. It immediately destroys its associated DOM window and renders a native-looking, historical "This program has performed an illegal operation and will be shut down" modal dialogue. The desktop environment itself remains completely stable and responsive.

12. Accessibility Considerations

Ensuring a fully truthful, WAI-ARIA-compliant accessibility layer while visually imitating a historic, fundamentally non-accessible operating system is the most demanding technical constraint of this architecture. Visual presentation must be entirely decoupled from semantic meaning2.

12.1. Modal Dialogs and Focus Trapping

Visual stacking via z-index does not translate to the DOM accessibility tree, which screen readers interpret linearly.

• Implementation must strictly follow the W3C WAI-ARIA modal dialog pattern19. The modal container requires role="dialog" and aria-modal="true"2.
• Focus Placement: Initial keyboard focus must never be set to the role="dialog" container itself. This obscures the focus location for low-vision users and creates overly verbose screen reader announcements20. Upon opening, focus must programmatically shift to the first interactive element inside the modal (e.g., a text input or the 'OK' button)3. Upon closing, focus must logically return to the trigger element that opened the dialog18.
• Inert Backgrounds: In a windowed OS, when a system-wide modal is open, background applications and the taskbar must become entirely inaccessible. The Window Manager must apply aria-hidden="true" and the inert attribute to all DOM nodes outside the active modal's subtree, effectively rendering them invisible to assistive technologies2.

12.2. System Notifications and the Clock

The OS clock and system tray notifications rely on visual updates that are inaccessible without intervention.

• The system clock must not be announced continuously by screen readers, as this would be highly disruptive. It should act as a static text element unless directly focused.
• Transient system notifications (e.g., "File saved" in the Ethics Workbench) must be injected into a visually hidden, absolute-positioned DOM container equipped with aria-live="polite". This tells the screen reader to announce the update naturally when it finishes its current sentence3.
• Critical system errors must utilize aria-live="assertive" or role="alert" to immediately interrupt the user and demand attention2.

13. Mobile/Degraded-Mode Behavior

An early-2000s desktop environment relies heavily on precise pointer interaction, complex drag-and-drop mechanics, and expansive viewport real estate. On mobile devices or constrained browsers, this paradigm fails fundamentally. The architecture must employ progressive degradation to maintain utility.

13.1. The Paradigm Shift

The Window Manager registers a ResizeObserver on the document body or utilizes CSS matchMedia listeners. When the viewport width drops below a critical threshold (e.g., 768px), the OS dynamically shifts from "Desktop Mode" to "Mobile Shell Mode".

1. Window Maximization: The multi-window overlapping visual metaphor is abandoned. All active windows are automatically maximized to fill the viewport, stripped of their resize handles, and detached from title bar dragging listeners.

2. Z-Index Suppression and Layout: Windows are restyled via a global .mobile-mode CSS class. Instead of floating, they are rendered as stacked panels, full-screen accordions, or a tabbed interface, ensuring only one application is visually dominant at a time.

3. Taskbar Transformation: The bottom taskbar transforms into a mobile-friendly bottom navigation bar or a consolidated hamburger menu, conserving vertical space.

4. Drag-and-Drop Disablement: File drag-and-drop logic is suspended. The architecture falls back to context menus or dedicated "Select File" buttons as the primary interaction methodology for operations like moving files or opening attachments.

This strategy ensures the core archive functionality remains accessible, usable, and performant, adhering strictly to progressive enhancement principles.

14. Performance Implications

A web-based desktop OS can rapidly suffer from DOM thrashing and memory leaks, leading to a severely degraded user experience, particularly on lower-end hardware.

14.1. DOM Layout Thrashing

Modifying DOM geometry (e.g., width, height, left, top) and subsequently querying it (e.g., getBoundingClientRect) forces the browser engine to perform synchronous style recalculations and layouts. As detailed in the Event Model, window manipulation must be batched. Calculations are performed in JavaScript variables, and the final state is applied strictly within a requestAnimationFrame loop using GPU-accelerated CSS transform properties12.

14.2. Memory Management

Because the environment operates as a Single Page Application without page reloads to clear the heap, the Process Manager must ruthlessly govern memory.

• Upon application termination, all bound DOM elements must be explicitly removed using Element.remove().
• Global window or document event listeners attached by the process must be rigorously detached using removeEventListener with the exact function signature originally registered.
• Internal state maps and caches within the application class must be set to null to sever references, allowing the browser's garbage collector to reclaim the memory8.

14.3. Asset Loading

Loading all applications concurrently during the initial boot sequence would cause unacceptable delays. Heavy applications—like the Cognitive Atlas visualization—should be code-split. Even without a bundler, vanilla JavaScript supports dynamic module loading via import('./apps/CognitiveAtlas.js'). The Kernel will lazy-load application scripts over the network only when a user actively executes the application, keeping the initial OS boot time near-instantaneous.

15. Security Implications

While the prohibition of external APIs and third-party dependencies inherently mitigates supply-chain attacks, client-side security must still be addressed, particularly regarding data parsing and the presentation of historical records.

15.1. XSS Prevention in the Archive

Because the OS reads historical files and renders them in the Document Viewer and Internet Explorer-style viewer, Cross-Site Scripting (XSS) is a severe risk if historical data contains embedded malicious scripts.

• The Window Manager and UI components must strictly use textContent rather than innerHTML when rendering file metadata, folder names, or plain text content.
• Complex HTML documents from the historical archive must be rendered inside heavily sandboxed \<iframe\> elements. These iframes must employ the sandbox="allow-same-origin" attribute, explicitly omitting the allow-scripts directive unless script execution is strictly required and heavily sanitized by the historical emulation layer9.

15.2. Backend Immutability

As established by the VFS overlay architecture, the PHP backend acts as the canonical source of truth. Security must be enforced at the backend level. The PHP API must be configured to strictly reject any POST, PUT, or DELETE HTTP requests. It must serve files exclusively via GET requests, ensuring immutability at the server level regardless of any client-side manipulation or malicious requests originating from the browser9.

16. Testing Strategy

Ensuring the stability of an intricate desktop simulation requires a layered testing approach that can be executed natively in the browser without relying on heavy testing frameworks like Jest or Cypress, adhering to the project's constraints.

1. Kernel Unit Testing: The core logic of the SystemState, ProcessManager, and VFS must be designed decoupled from the DOM. This allows them to be unit-tested in isolation by writing lightweight vanilla JS assertions that mock the IWindowManager and validate state transitions and matrix calculations.

2. Integration Testing: Utilizing a custom test runner built in vanilla JS, engineers must test the Bootloader sequence: ensuring that an event published on the SystemBus correctly triggers a subscribed application to change state, and that file reads resolve properly through the IndexedDB overlay logic.

3. Accessibility Auditing: The architecture relies heavily on exact WAI-ARIA implementations. Manual testing with screen readers (NVDA on Windows, VoiceOver on macOS) is mandatory. The QA process must specifically target the focus trap mechanics of modal dialogs and the announcement of dynamic aria-live regions2.

17. Recommended Implementation Phases

To de-risk the engineering process and manage complexity, the architecture should be implemented in strictly defined, sequential phases:

• Phase 1: Foundation (Kernel & VFS). Implement boot.js, the SystemBus, and the VFS overlay system utilizing IndexedDB and Fetch. At this stage, the OS runs entirely in the browser console. Applications can be instantiated and files read, but nothing renders visually.
• Phase 2: Window Management & DOM Projection. Construct the core desktop DOM structure. Implement the WindowManager to project Kernel state into draggable, resizable \<div\> elements. Establish the z-index orchestration algorithm and requestAnimationFrame drag loops.
• Phase 3: The Shell. Build the Taskbar, Start Menu, Desktop Icons, and System Clock. Link these elements to the SystemBus to visually reflect real-time process data and system time.
• Phase 4: Application Development. Develop the specific application classes: Research Explorer, Read-Only Cyber Console, Cognitive Atlas, and Ethics Workbench. Map their specific file associations within the VFS.
• Phase 5: Routing & Persistence. Wire the HTML5 History API to the active window state for URL synchronization. Implement the serialization layer saving the desktop state to IndexedDB for session restoration.
• Phase 6: Accessibility, Polish, & Mobile. Implement all required WAI-ARIA roles, focus traps, and keyboard navigation listeners. Construct the @media queries and ResizeObserver logic for degraded-mode transformations. Apply historical CSS theming to finalize the visual emulation.

18. Definition of Done

A convincing, architecture-compliant desktop shell is considered unequivocally "Done" when the following criteria are met and verifiable by the engineering team:

1. Constraint Adherence: A full audit of the browser's Network tab confirms zero requests to external CDNs, zero third-party script files loaded, zero npm runtime dependencies present in the source, and zero remote analytics or tracking pings executing.

2. OS Cohesion: Applications can be launched, minimized, maximized, focused, dragged, and closed seamlessly. The Z-order calculation correctly surfaces clicked windows and demotes background windows instantaneously, without triggering noticeable DOM layout thrashing or frame rate drops.

3. Data Integrity Verification: Users can visually "delete", "rename", or "edit" a file in the Research Explorer, but a direct backend GET request or database inspection of the canonical PHP backend confirms the original file remains entirely unmodified. All mutations exist solely within the local IndexedDB overlay.

4. Deep Linking Functionality: Pasting a specific, complex URL (e.g., pointing to a nested file in the Cognitive Atlas) into a fresh, incognito browser tab boots the OS, bypasses the idle desktop state, and directly opens the specific application and file represented by the URL.

5. Accessibility Compliance: Navigating the entire OS using only the Tab, Arrow, Enter, and Escape keys is fully functional. Opening any system modal or child window completely traps keyboard focus within that modal, and aria-modal="true" combined with the inert attribute successfully prevents background elements from being exposed to the accessibility tree.

6. Mobile Degradation: Loading the environment on a device with a 375px wide viewport automatically suppresses all floating window mechanics, disables complex drag-and-drop, and flawlessly reverts to a stacked, touch-friendly, and accessible mobile interface.

By executing this comprehensive architectural blueprint, the engineering team will deliver a robust, historically evocative, and highly accessible digital archive. The resulting product will function fundamentally like an operating system, achieved entirely through rigorous, standard-compliant vanilla web technologies.

Works cited

1. Accessible Rich Internet Applications (WAI-ARIA) 1.3 \- W3C on GitHub, https://w3c.github.io/aria/

2. What Is ARIA? A Guide to Accessible Web Components, https://wpdean.com/what-is-aria/

3. Coding web applications using advanced ARIA techniques | Mass.gov, https://www.mass.gov/info-details/coding-web-applications-using-advanced-aria-techniques

4. VibeOS vs. Cloud Services: A General Architectural Breakdown, https://www.reddit.com/r/vibeoscloud\_official/comments/1ufbrww/vibeos\_vs\_cloud\_services\_a\_general\_architectural/

5. Windows 98 Web Edition \- GitHub, https://github.com/azayrahmad/win98-web

6. meese-os/meeseOS | DeepWiki, https://deepwiki.com/meese-os/meeseOS

7. Universal File Access Gateway \- How I turn my own Web Desktop, https://dev.to/tobychui/universal-file-access-gateway-how-i-turn-my-own-web-desktop-os-into-a-gateway-for-all-my-file-servers-3oi8

8. LinuxUI (LUI) \- Web-Based Desktop Environment 🏗️ (WIP) \- GitHub, https://github.com/Damarcreative/LUI

9. GitHub \- tobychui/arozos: Web Desktop Operating System for low, https://github.com/tobychui/arozos

10. Dialogs \- Material Design, https://m2.material.io/develop/web/components/dialogs

11. Focus Manager \- GitHub Pages, https://isaacandela.github.io/focus-manager/

12. Mentalist OS \- Stardance, https://stardance.hackclub.com/projects/38477

13. GitHub \- goph-R/WebWin7: A small pure HTML \+ CSS \+ JavaScript, https://github.com/goph-R/WebWin7

14. Introducing the popover API | Blog \- Chrome for Developers, https://developer.chrome.com/blog/introducing-popover-api

15. vispo/ZIndexMgr: A JavaScript zIndex manager for ... \- GitHub, https://github.com/vispo/ZIndexMgr

16. Absolute Beginners Intro To WAI-ARIA, https://www.nordburg.ca/tutorials/aria/

17. A custom-built, interactive front-end portfolio designed with ... \- GitHub, https://github.com/meswapnadeeppal/meswapnadeeppal.github.io

18. WAI-ARIA Authoring Practices 1.1 \- W3C, https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/

19. Accessibility Considerations for Off-Site Navigation and Downloads, https://buttondown.com/access-ability/archive/accessibility-considerations-for-off-site/

20. Modal Dialog Example | APG | WAI \- W3C, https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/

21. Colton-Ko/ArOZ-Online-System: Web Desktop Platform for ... \- GitHub, https://github.com/Colton-Ko/ArOZ-Online-System