guideXOS Server Application Model
Purpose: explain manifests, built-ins, Native ELF, GXAPP packaging, launch resolution, and the hosted versus bare-metal split.
What exists today
The current docs/APP_MODEL_CURRENT_STATE.md shows a real hosted manifest model and a separate bare-metal kernel app model.
That is the most important fact to understand: guideXOS Server already has meaningful app-model machinery, but it is not yet one unified runtime path across every environment.
Current status: hosted manifest and packaging work is real and active.
Known gaps: a single unified runtime path across hosted and bare-metal environments is not finished yet.
Back to /Wiki/Server
Current app kinds in the repo
| Kind | Repo Evidence | Current State |
|---|---|---|
| BuiltIn | app_manifest.h, built_in_app_metadata.h, desktop_service.cpp, kernel/core/kernel_apps.cpp |
Implemented |
| NativeElf | native_elf_launch_pipeline.cpp, native_app_runtime.cpp, SDK docs, experimental build scripts |
Experimental |
| GXAppPackage | gxapp_container.cpp, package_manager.cpp, GXAPP_FORMAT_SPEC.md |
Partial |
| Service / Script / HypervisorGuest | AppKind enum and launch resolver surface |
Planned / In Design Surface |
Hosted app registry
app_registry.cpp scans /system/apps, /Apps, /users/default/apps,
sdk/samples, and examples/apps for app.json files. It also mirrors hosted built-ins as synthetic manifests.
Bare-metal app registry
Bare-metal does not currently use the hosted manifest registry as the authoritative launch source. It uses kernel app registration in
kernel/core/kernel_apps.cpp and launch paths in kernel/core/desktop.cpp.
Built-in apps surfaced in metadata
The shared built-in metadata table includes apps such as Notepad, Calculator, Clock, Console, FileExplorer, Trash, TaskManager, Paint, ImageViewer, OnScreenKeyboard, ShutdownDialog, DiskManager, ControlPanel, DisplayOptions, guideXOS Navigator, App Model Demo, Native App Debug Viewer, and HDInstaller. Availability flags show which ones are intended for hosted mode, bare-metal mode, or both.
Native ELF today
- Normal hosted builds do not enable full Native ELF execution.
build-native-experimental.batenables trusted local hosted-runtime validation.- Current support is intentionally narrow: amd64 host, amd64 app, static
ET_EXEC, no dynamic linker, no relocations, no broad host filesystem access. - SDK sample build/staging exists and can populate
Apps/HelloWorldand related hosted paths.
GXAPP packages today
The package format is not just an idea: the repo includes a formal spec and install logic. The current format uses a magic-header container,
metadata entry, and one or more architecture-specific binary entries. The package manager validates architecture support, stages packages under
/system/apps/.staging, and then installs into /system/apps using safe rename behavior.
The wider universal-application story is still broader than today’s end-to-end runtime path. Container format and install flow are ahead of full universal execution.