Technical architecture

How SBOS runs software

SBOS separates stored packages, runtime environments, operating-system state, user data, devices, and network access. Each application receives only the files, devices, network access, and operating behavior that SBOS assigns to it.

Core operating system

Star System Kernel

The Star System Kernel is the SBOS kernel. It controls process authority, scheduling, resources, device access, and the boundaries between applications and the operating system.

Star-Blade File System

SBFS governs immutable system and core files, system state, application state, user data, snapshots, rollback and recovery, integrity information, and storage-efficient inactive application environments.

Immutable core

System and core files are immutable by design. Applications, SBN trustee rights, and ordinary administrator workflows do not rewrite the immutable core directly.

Userland

SBOS userland includes the desktop shell, settings, app management, prompts, diagnostics, service dashboards, server tools, and administration workflows.

Native .sba application lifecycle

  1. The user opens the .sba bundle.
  2. SBOS validates its package and integrity information.
  3. SBOS reads its manifest and metadata.
  4. The application is registered or updated in the SBOS App Registry.
  5. SBOS materializes the application runtime environment.
  6. App-local dependencies, files, configuration, permissions, devices, network rules, and resource rules are attached.
  7. The application starts.
  8. SBOS continues tracking lifecycle, diagnostics, reset, repair, recovery, movement, removal, inactive-state compression, and updates.

The stored package remains separate from the runtime. The App Registry is not the Windows Registry. It can track application identity, version, hashes, integrity state, size, storage use, package location, runtime location, ownership, installer and runner information where applicable, permissions, compatibility profile, update state, diagnostics, lifecycle state, and repair or recovery state.

Compatibility lifecycle

  1. Identify the application format and originating platform.
  2. Determine whether the launched file is an installer, updater, launcher, or actual application.
  3. Infer the operating-system version, distribution, runtime, dependency, filesystem, and API behavior the application expects.
  4. Create or select the correct app-specific compatibility environment.
  5. Run an installer inside that environment when the launched file is an installer.
  6. Observe the installation process and identify the actual installed application.
  7. Register the resulting application with SBOS.
  8. Keep files, dependencies, configuration, caches, services, and application-local state within the environment.
  9. Apply a known profile, a generic fallback profile, or locally refined behavior.
  10. Combine a newer compatibility profile with safe settings already learned for that application on the local system.

Application boundaries

Processes

Applications cannot freely list unrelated processes or inspect and edit unrelated process memory. Cross-process access requires explicit SBOS authority.

Files

User files are provided through a file picker, explicit permission, User Policy, or administrator rule. Application settings and dependencies remain associated with the application.

Network

Applications can receive separate network views. Outbound access, inbound access, localhost visibility, and app-to-app networking can be controlled per app.

Devices

Storage, controllers, cameras, microphones, capture devices, VR hardware, screen capture, window capture, and other devices are brokered.

Diagnostics

SBOS diagnostics focus on system faults. They can report crashes, stack traces, invalid states, freezes, performance problems, dependency failures, API translation failures, compatibility events, service health, and application lifecycle failures. Processing begins on the local device, transport is encrypted, and each report uses a defined diagnostic format for compatibility, stability, security, and fault investigation.

Installation, provisioning, and updates

Installation follows a direct sequence: boot the installer, enter the activation code when required, complete server-authorized provisioning, review the required terms and prompts, install SBOS, then boot into the provisioned system. Updates are staged separately from active system state, validated before commitment, and applied through the SBOS update process with rollback or recovery paths.

Virtualization

SBOS has three separate concepts: application environments, the SBOS native hypervisor for full virtual machines, and VMware or VirtualBox running as third-party compatibility applications. In eligible volume-licensed deployments, an SBOS guest can inherit host trust and licensing state only through the SBOS native hypervisor. External hypervisors do not receive that inheritance.

Major server architecture

SBOS Server can run Server Suite roles, App Collections, FST ID, SBGS, SBN, hosting, mail, file services, cloud-style file services, containers, native virtualization, remote access, backup, monitoring, deployment management, audit, and diagnostics. Capabilities can be deployed together or separately according to role requirements.