Compatibility

How SBOS runs Windows, Linux, and macOS apps

Compatibility applications keep their own platform identity. SBOS prepares the environment each application expects while retaining control over files, processes, networking, devices, permissions, and lifecycle state.

Windows applications

SBOS can identify PE executables, .exe files, .msi packages, installers, launchers, updaters, and the applications those installers create. Metadata, copyright dates, embedded compatibility declarations, libraries, and runtime behavior help determine the Windows version and system behavior an application expects.

Linux applications

Linux handling distinguishes ELF applications, .deb packages, and .rpm packages. Package metadata, distribution-family conventions, libraries, filesystem expectations, services, and launch behavior are used to build the appropriate Linux-oriented environment.

macOS applications

macOS handling reads Mach-O binaries, .app bundles, property lists, bundle metadata, frameworks, and version hints. Profiles can account for current macOS behavior as well as older Mac OS X expectations when an application requires them.

Shared compatibility lifecycle

  1. Identify the file, originating platform, application identity, and whether it is an installer, updater, launcher, or program.
  2. Determine the operating-system version, distribution, runtimes, libraries, filesystems, services, and APIs the application expects.
  3. Create or select the app-specific compatibility environment.
  4. Run an installer inside that environment and observe the application or applications it creates.
  5. Register the installed application with the SBOS App Registry.
  6. Keep its files, dependencies, configuration, caches, services, and local state inside the same environment.
  7. Apply a known profile, a conservative generic profile, or settings refined from the application’s local behavior.
  8. Combine later compatibility updates with safe settings already learned for that application on the system.

Games, media, VR, creative work, and development

Games and anti-cheat

Games and launchers use normal compatibility environments. Anti-cheat-sensitive software can receive the expected platform behavior and narrowly brokered permissions without being given unrestricted control over the SBOS host.

Media and creative applications

Media, editing, audio, MIDI, capture, encoding, DRM playback, hardware decoding, graphics, and device access are connected through the application environment and SBOS brokers.

Development tools

Editors, SDKs, engines, compilers, emulators, containers, local services, build tools, and virtualization software keep their dependencies and access rules with the application.

Compatibility limits

Some software expects unrestricted kernel drivers, process access, localhost services, capture surfaces, VPN routing, or direct hardware control. SBOS can deny the request, ask the user, require an administrator policy, provide a narrower brokered path, or use a full virtual machine when that is the appropriate boundary.

Compatibility varies by application, game, launcher, anti-cheat system, driver, device, and version.