e04ca28812
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.
27 lines
1.2 KiB
Markdown
27 lines
1.2 KiB
Markdown
# 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.
|