Linux programs · XerisOS Docs

run /APP.ELF can start another Linux ELF while an existing app remains open. The first app uses the retained primary session. Later static PIE and dynamic ELFs get their own PID, address space, descriptor table, and stack. Dynamic GUI launches also get a private interpreter and native window. A Wayland connection retains the descriptor table and desktop owner of the process that opened it, so two applications can draw and receive input without replacing each other's surface. The native X terminates only the selected independent process tree.

The primary session retains its page-table root because cross-CPU page-table retirement is unfinished. Once it has bootstrapped, every later launch uses an independent process even if the primary app's threads have already stopped; trying to reload the retained primary session could clear the Linux runtime state after an error. Capacity still depends on RAM, the 64 process slots, 512 thread slots, 24 independent GUI window slots, and 48 Wayland connection slots. These are resource limits, not a promise of unlimited simultaneous applications.

LibreOffice independent launches use their installed or live-USB library and GTK environment, plus a disposable per-process profile to avoid its single-profile lock. Documents remain in owner storage. The disposable profile's preferences do not persist across launches; the primary Office profile keeps its existing persistent behavior.

Verification (2026-10-06)#

mingw32-make build/kernel.bin -j4 builds the production kernel, and git diff --check passes.
In an isolated 2-vCPU QEMU guest, a primary static ELF and two independent dynamic ELF processes ran concurrently with distinct PIDs. The independent processes survived the primary's exit.
Two independent Wayland test clients painted separate red and blue windows in the same guest. Closing the blue native window left red drawing. Launching blue again connected to the compositor and drew a new frame.
An earlier candidate launched an immediate-exit ELF eleven times without a reboot. The current launcher uses independent processes after its first session; it also launched an ELF after a secondary Chromium crash.
With a primary ELF still active, a separate dynamic ELF forked, exec'd a second ELF, waited for its exit status, and reported FORKEXEC PASS.
In a separate Chromium run, two Web windows painted. Closing the second left the first visible, and a third launch painted. Another run exposed an intermittent secondary Chromium page fault. After that exit, the current launcher reclaimed its disposable profile (184 files, 60 directories), launched an ELF, and painted a new Chromium window. That browser later faulted too; repeat-launch recovery is verified, sustained concurrent Chromium stability is not.
The test files and serial traces are in the ignored build/multi-instance-smoke-20261006 directory. No OTA was signed or published for this change.

The full Chromium, OBS, Minecraft, and LibreOffice payloads still need same-build mixed-app stress testing on the target hardware. Chromium's single-AP guard remains in place while synchronous cross-core permission revocation is unfinished; increasing its advertised CPU count without that mechanism would make memory guards unsafe. Minecraft currently shares that single-AP safety gate, so a one-core report is expected until the page-table shootdown path is implemented and validated.