# projects/

Things that run **on** SchOS rather than things that **are** SchOS.

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 SchOS
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/`  | SchOS Compositor. v0 runs; the plan is for it to draw the installer, and later a desktop (SchDE) on top. |
| `schinst/` | The installer, the installation environment, and `.sip` tooling. |
| `schfs-linux/` | SchFS as a filesystem for Linux. FUSE first, a kernel module later. |

`schwm/` and `schde/` used to be here and were **deleted**: both held a README and no code. The window manager
is Schcom's own business now (a compositor is its window manager), and **SchDE**, a panel, launcher and the rest,
comes back as ordinary clients of Schcom once there is something for them to run on. Until then the desktop is
Xorg with Window Maker ([`docs/architecture/desktop.md`](../docs/architecture/desktop.md)).

**`schfs-linux/` is written to stand on its own.** It does not mention SchOS
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.

Nothing here is a dependency of the kernel build, and nothing here is pointed at
by anything above it.

## Status

`schcom/` is a compositor v0, 715 lines that run, over a wire format of its own. It is **kept, with a job**: the
installer's GUI ([`docs/plan/roadmap.md`](../docs/plan/roadmap.md) §5) is its first real client, and if it grows
into something actually useful it becomes SchOS's own desktop, SchDE on top. Everything it was blocked on in the kernel
exists (Unix sockets, descriptor passing, `memfd`, evdev, framebuffer `mmap`); what it lacks is a protocol designed for
real clients and the clients themselves.

`schinst/` and `schfs-linux/` are scoped and unstarted, and are **frozen** -- see
[`docs/plan/1.0.md`](../docs/plan/1.0.md).