SchOS/.claude/memory/schunix-roadmap-and-projects.md

name	description	metadata
schunix-roadmap-and-projects	The agreed roadmap through USB, GPU, fonts, network and the GUI; Schcom/SchWM/SchDE and the installer live in projects/, outside the OS tree	node_type type originSessionId modified memory project a665e14b-86bd-4b41-a228-51377f3e9225 2026-08-09T20:20:11.342Z

Set out 2026-08-04. Recorded in docs/roadmap.md; the naming and the split are Nexoniarz's.

Order asked for: USB → GPU → OTF/TTF → network + sockets → GUI → installer. Kept, with one dependency fix: shared driver infrastructure came first (schunix-driver-infrastructure), because it was the first step of USB rather than a detour from it.

The GUI stack, all three named by Nexoniarz and all in projects/:

• Schcom — Schunix Compositor. Owns the display and input; composites client buffers. Policy is not its job.
• SchWM — window manager, a privileged Schcom client.
• SchDE — desktop environment: panel, launcher, settings.
• schinst — installer, installation environment, and .sip tooling.

projects/ is at the repo root and is not part of the kernel build — things that run on Schunix, not things that are Schunix. They link against the sysroot libc and never against kernel headers. The reason is that each is larger than the kernel will be for a long time, and grown in-tree the boundary would blur until "does Schunix boot" stopped having a clear answer.

The two hard blockers before Schcom can start, both kernel work:

1. Unix domain sockets. socket() is still a NO_LINUX stub. Needed for the client protocol and for SCM_RIGHTS — a pipe cannot carry a buffer handle. Build these before TCP/IP; they are simpler and they are what the socket layer's shape should be designed around.
2. Raw input events — an evdev-style /dev/input. Input only arrives cooked through the tty line discipline, line-buffered to one foreground process, which is not usable by a compositor.

shm and framebuffer mmap are already done (schunix-shm-and-mmap).

.sip = Schunix Installation Package, modelled on WIM: file-based rather than block-based, so one file holds a whole tree, applies to any partition size, and dedups across images. Most of it exists — tools/mkschfs.c and tools/mkfs.c already do content dedup with an (st_dev, st_ino) fast path. mksip should share that code.

Order changed 2026-08-09: Schcom and SchAPI come before the installer

Nexoniarz: the GUI stack is what is actually needed, the installer can wait. Schcom v0 is done — see schcom-v0. SchAPI/libschunix is still not started, and is the other half of what was asked for.

projects/ has build glue now: make projects builds against the sysroot libc and stages into sysroot/bin. It is not a dependency of the OS build and make never descends there.

The installer, scoped 2026-08-09 (deferred, not cancelled)

A live CD is off the list. The ISO boots a complete system from the ramdisk, so it already is the live environment; an installer makes a mountable disc redundant. That drops the ATAPI driver and ISO 9660 filesystem entirely — see schunix-iso-boot.

Nexoniarz chose the ambitious shape on both open questions:

• Both firmwares from the start: GPT with a FAT ESP and a SchFS partition, bootable on BIOS and UEFI. Needs a FAT writer and GPT code inside the OS before anything can be installed at all.
• .sip first, rather than copying the running root. The installer applies a package; mksip comes before anything installs.

Dependency chain, each stage separately verifiable:

1. Raw block device — done, commit 66152ad. /dev/hda, /dev/hdb, major 8, minor = IDE device number. Verified against the host as an independent oracle in both directions. Limit: devsw passes the offset as a 32-bit uint, so a raw disk stops at 4 GB — widen before installing to real hardware.
2. .sip format + mksip, sharing the dedup path in mkschfs.c. Test it the way the SchFS round-trip is tested: build, apply, diff -r against the source tree (schfs-phase2-mount).
3. In-OS tooling: GPT writer, FAT ESP writer, native SchFS formatter.
4. Bootable target: bootblock + stage2 for BIOS, ESP + BOOTX64.EFI + kernel for UEFI.
5. schinst in projects/, driving all of it.

Confirmed order (2026-08-05): finish USB, then sockets + raw input, then virtio-gpu.

Doom moved (2026-08-05). It was "explicitly last"; it is now the acceptance test — "an OS that doesn't run Doom is not a real OS". fbDOOM at that. It is a real load test: framebuffer mmap, raw termios, file I/O, allocator and timing, all at once. Everything on that list already exists except possibly gettimeofday/nanosleep resolution, so it could be attempted today — it needs no sockets, USB, virtio-gpu or fonts. It is a test, not a component — clarified by Nexoniarz: built and run to prove things work, never shipped in the system. That disposes of licensing entirely, since nothing is redistributed. Belongs with the test tooling (a make doomtest, same shape as make crashshot), not in cmd/ or the sysroot. If it were ever shipped the licensing returns: engine is GPL-2.0 (fine in ports/, never cmd/), and the WAD would have to be Freedoom (BSD-3-clause) because doom1.wad is not redistributable.

Sized honestly and not to be underestimated: OTF/TTF is a rasteriser plus a variable-width glyph cache, and the console assumes a fixed 8x16 cell grid throughout — proportional text is a new rendering layer, not a font swap.

Fonts must be public domain or very permissive — "PD0", clarified 2026-08-05 (the earlier note read it as "CY-NO", which was never a real thing). CC0 is ideal; MIT/BSD/Apache fine. SIL OFL is usable but carries a rename-if-modified obligation, so read it first. A font ships inside every image, so its licence attaches to the image — see schunix-licensing.

First GPU driver should be virtio-gpu, not Intel/AMD: public spec, QEMU implements it, and it teaches the resource/flush model that a raw framebuffer never will. Doom stays last. See nexoniarz-sharing-preference.