SchOS/projects/schwm/README.md
Nexoniarz e04ca28812 Rename Schunix to SchOS; the kernel becomes SchIFT
Removes the "-unix" element and with it any trademark exposure to The
Open Group.

The split follows the ecosystem layout: SchOS is the system, and the
kernel has its own name. Kernel-identity strings are the only places
that take SchIFT -- uname(2) sysname, /proc/version, and the two licence
sentences that say "kernel" outright. That is what every Unix does here:
`uname -s` on Linux reports the kernel, not the distribution. Everything
a user reads as the product -- panic screen, boot menu, error prefixes,
docs, LICENSE, NOTICE -- is SchOS.

schunix.img is schos.img, the logo assets and the musl TLS patch are
renamed, and __SCHUNIX__ is __SCHOS__ (the define and the patch that
consumes it moved together).

Two things the rename broke, both found by the bootcheck suite:

  - shmtest wrote "SCHUNIX-MMAP-OK" with a hardcoded length of 15 and
    compared it back by hand-counted offsets (m[3]=='U', m[14]=='K').
    The shorter marker left the write running two bytes past the literal
    and the compare reading past the data, failing a file-backed mmap
    that was working correctly. Now written and compared through one
    constant with sizeof.
  - bootcheck asserted a 31-byte file after appending to
    "hello-from-schunix"; the shorter string makes it 29.

Both are the same mistake: a string literal whose length is written out
somewhere else. Full suite green -- base, Tty, Ps, Sock, Fb, Usb, Evdev.
2026-08-09 14:09:59 +02:00

1.2 KiB

SchWM — the SchOS Window Manager

Policy. Where windows go, which one has focus, what happens when you drag a title bar, how alt-tab behaves, what a window looks like at its edges.

SchWM is a client of Schcom, not part of it. It talks the same protocol every other client does, plus a privileged extension that lets it position and stack surfaces it does not own. That extension is the entire difference between a window manager and an ordinary application.

Status

Not started. Blocked on Schcom, which is blocked on the kernel — see ../schcom/README.md.

Why it is separate from the compositor

Merging them is the common shortcut and it is the one that hurts later. Compositing is mechanical and must never stall: it runs every frame and a mistake there is a frozen screen. Window management is policy, full of special cases and personal taste, and it changes constantly. Putting them in one process means every experiment with focus behaviour risks the thing that puts pixels on the screen.

Keeping them apart also means SchWM can be restarted, replaced, or simply not run. A Schcom with no window manager should still show a full-screen client — that is a useful state to be able to reach when something is wrong.