SchOS/projects

projects/

Things that run on Schunix rather than things that are Schunix.

Everything above this directory — kernel/, boot/, lib/, cmd/, include/ — is the operating system: it boots, it owns the hardware, and it is one program that either works or does not. Everything in here is an ordinary program that talks to it through syscalls, exactly as toybox does.

The split exists because the alternative gets bad quickly. A compositor, a window manager and a desktop are each larger than the kernel will be for a long time. Grown inside the OS tree they would blur into it: a compositor would start reaching into kernel headers because they are right there, the build would grow a dependency from the kernel to a GUI, and "does Schunix boot" would stop having a clear answer. Keeping them separate forces the boundary to be a real interface — syscalls and protocols — rather than a shared header nobody meant to share.

Concretely, code in here:

• links against the sysroot's libc, never against kernel headers
• talks to the kernel only through syscalls and /dev
• can be built, run and debugged without rebuilding the kernel
• may be split into its own repository later without untangling anything

What lives here

Directory	What it is
schcom/	Schunix Compositor. Owns the display, composites clients, routes input.
schwm/	Schunix Window Manager. Window placement, decoration, focus, on top of Schcom.
schde/	Schunix Desktop Environment. Panel, launcher, settings, file manager.
schinst/	The installer, the installation environment, and .sip tooling.
schfs-linux/	SchFS as a filesystem for Linux. FUSE first, a kernel module later.

schfs-linux/ is written to stand on its own. It does not mention Schunix anywhere, and that is deliberate rather than an oversight: it is intended to be the first piece released, and it has to make sense to somebody who has never heard of the OS it came from — a filesystem is judged as a filesystem. The connection can be made later, once there is a finished system to connect it to.

Practically, that means anything added there needs its own licence header, its own README framing, and no cross-references into this tree. It shares the format with kernel/fs/schfs/, not the prose.

They stack: SchDE needs SchWM needs Schcom needs the kernel. Nothing points the other way, and nothing here is a dependency of the kernel build.

Status

All four are scoped and none is started. What each is waiting on is written in its own README, and the ordering is in docs/roadmap.md.

The short version: Schcom cannot start until the kernel has unix domain sockets (for the client protocol and for passing buffer handles) and raw input events (a /dev/input that bypasses the tty line discipline). Shared memory and framebuffer mmap are already done.