Building a Unix-like Operating System in the Browser with IndexedDB VFS and IPC

The article presents yOS, a browser-based operating system, as a practical example of applying traditional OS architectural principles within a web environment. This showcases how concepts typically found in low-level system programming can be translated and implemented using web technologies to achieve similar functionalities.

Core Architectural Components

yOS is built on several key components that mimic a traditional Unix-like OS structure, adapted for the browser context:

• Lean Kernel: Provides minimal core services such as process tracking, VFS access, socket communication, and application execution. It delegates display and complex application logic to userspace, emphasizing a clear separation of concerns.
• IndexedDB Virtual Filesystem (VFS): All applications and files are persistently stored in IndexedDB. It employs an `ext4`-inspired INode and Block architecture, allowing Unix-like `open`, `read`, and `write` operations for file management within the browser's local storage.
• Inter-Process Communication (IPC) via Domain Sockets: Facilitates communication between processes using a custom implementation of domain sockets. This is crucial for modularity, allowing the display server and individual applications to communicate securely and efficiently.
• Self-Contained Applications: Applications are compiled into single IIFE JavaScript files and loaded from the VFS. They interact with the kernel through exposed primitives, maintaining isolation and security, similar to how applications run in a sandboxed OS environment.

IndexedDB VFS Implementation Details

The IndexedDB VFS is a core system design element, demonstrating how persistent storage can be achieved in a browser environment. It maps Unix file operations to IndexedDB transactions, managing INodes and data blocks. This design choice highlights trade-offs between web-native storage capabilities and the desire to emulate a traditional filesystem structure.

/* VFS Controller _readBlock, _readINode and similar calls utilize IDBDriver for persistent file operations */
async open(path: string) {
  const { parent, name } = await this._resolvePath(path);
  const parentDir = this._decodeDirBlock(await this._readBlock(parent.id));
  let node: INode;
  if(parentDir[name] === undefined) {
    node = await this._createFile(parent, name, FileType.FILE);
  } else {
    node = await this._readINode(parentDir[name]);
    if(node.type !== FileType.FILE) {
      throw new Error(`${name} is not a file`);
    }
  }
  return { id: this._fdCounter++, inode: node.id, position: 0 } as FileDescriptor;
}
async read(fd: FileDescriptor, length: number): Promise<Uint8Array> {
  const inode = await this._readINode(fd.inode);
  if(inode.type !== FileType.FILE) {
    throw new Error("Cannot read from a directory");
  }
  const block = await this._readBlock(inode.id);
  const data = block.slice(fd.position, fd.position + length);
  fd.position += data.length;
  return data;
}
/* IndexedDB driver */
async read(store: string, key: IDBValidKey) {
  return new Promise<any>((resolve, reject) => {
    const transaction = this._db.transaction([store], "readonly");
    const objectStore = transaction.objectStore(store);
    const request = objectStore.get(key);
    request.onerror = (event) => {
      reject(new Error(`IndexedDB error: ${request.error}`));
    };
    request.onsuccess = (event) => {
      resolve(request.result);
    };
  });
}