guideXOS Server Architecture

Purpose: show how the current Server branch separates boot, kernel, hosted desktop, and application work.

Layering principle

The repository README and server.cpp both push the same architectural idea: the bootloader loads the kernel, the kernel is the boot-aware layer, and user-facing desktop/application behavior should live above that boundary. The repo is still evolving, but the intended separation is explicit.

Firmware -> Bootloader -> Kernel -> guideXOSServer -> Applications

Current status: implemented architectural direction with active layering work.
Known gaps: hosted and bare-metal parity plus some app-model boundary cleanup are still evolving.
Back to /Wiki/Server

Current architectural boundaries

Layer Repo Evidence Responsibilities Status
UEFI bootloader guideXOSBootLoader/main.cpp, elf.cpp, paging.cpp, GOP and ACPI headers Open kernel file, build boot info, manage memory-map handoff, exit boot services, and transfer control to the kernel. Implemented
Kernel core kernel/core/main.cpp, storage/network/input/desktop/VFS code Boot awareness, framebuffer setup, interrupts, storage, VFS, networking, input, and kernel desktop/app infrastructure. Implemented
Architecture-specific runtime kernel/arch/* directories for amd64, x86, arm, arm64, ia64, loongarch64, mips64, ppc64, riscv64, sparc, sparc64 Boot assembly, linker scripts, console/display hooks, architecture-specific syscall/context-switch/device code. Partial
Hosted system server server.cpp, compositor.cpp, desktop_service.cpp User-mode init/server role, compositor/window manager, desktop services, app launching, IPC, VNC, and hosted diagnostics. Implemented
App registry and packaging app_registry.cpp, app_manifest*.cpp, app_launch_resolver.cpp, package_manager.cpp, gxapp_container.cpp Manifest scanning, built-in metadata mirroring, launch resolution, package validation, and staged install paths. Partial

Kernel responsibilities

  • Boot method handling for UEFI BootInfo and Multiboot-style paths in current code
  • Framebuffer initialization and early desktop draw
  • Interrupts, PIT, PS/2 input, serial debugging
  • Block devices, ATA, NVMe, RAM disk, VFS, filesystem drivers
  • Kernel networking and feature reporting
Implemented

Hosted desktop responsibilities

  • Window manager and compositor
  • Taskbar, start menu, wallpaper, desktop icons, selection, drag/drop-like interactions
  • Desktop app launching and filesystem opening rules
  • Hosted diagnostics such as app-model and Navigator smoke paths
Implemented

Application-model split

The current repo does not yet show a single unified app-model backend used identically everywhere. The hosted path uses the manifest loader, registry, launch resolver, and desktop service. The bare-metal path still has a separate kernel app manager and registration flow in kernel/core/kernel_apps.cpp and kernel/core/desktop.cpp.

That means the architectural target is clear, but some launch behavior and built-in registration still exist in parallel hosted and bare-metal implementations.

Where boundaries are still evolving

  • Manifest-driven launches: present and useful in hosted mode, but still hybrid in execution.
  • GXAPP runtime story: container and install flow exist, but the broader universal-app path is still maturing.
  • Hosted vs bare-metal parity: some built-ins exist in both environments, but not all desktop behavior is proven identical.
  • Architecture breadth: many architecture directories exist, but maturity clearly differs between targets.