# 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. Owns the display, composites clients, routes input. |
| `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 have been **deleted**. In Wayland the
compositor *is* the window manager — there is no protocol by which a second
process places another's windows — and a panel or a launcher is an ordinary
client that needs no home of its own until one is written. Both directories held
a README and no code, and both had said "to be deleted" for long enough to prove
that a directory marked for deletion is not deleted by being marked. What they
argued for survives as a module boundary inside Schcom; see
[`docs/plan/wayland.md`](../docs/plan/wayland.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/` has a v0: 715 lines that run, over a wire format of its own. **That
wire format is superseded** — the compositor moves onto Wayland, keeping the
architecture and replacing the protocol. See
[`docs/plan/wayland.md`](../docs/plan/wayland.md).

Everything Schcom was blocked on in the kernel now exists: unix domain sockets,
raw input events, shared memory, framebuffer `mmap`, and — as of the descriptor
passing work — `SCM_RIGHTS`, which is the one thing a Wayland client cannot be
written without. What is still missing is a **shareable memory object**, item 2
of [`docs/plan/foundations.md`](../docs/plan/foundations.md): a Wayland buffer
is a file descriptor for memory, and a System V segment id is not one.

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