Last time, Space Invaders became the first Rainbow-OS program to live outside
the kernel. Getting it there was real work: a new batch of syscalls, a little
userland SDK, and three subtle bugs to chase down. This time I moved a second
game — Asteroids — out of the kernel too. The interesting part isn’t
the game. It’s how little it cost.
The second one was almost free
Porting Asteroids took one file copy and a search-and-replace. Every kernel
call became the syscall I’d already built for the first game: draw the back
buffer, read the keys, check the clock, sleep a frame. No new syscalls. No kernel
changes at all. Compile it with the same build script, drop it in the disk image,
delete the old copy from the kernel tree. Done.
That’s the whole point of an abstraction, and it’s satisfying to watch it pay
off. The first app forces you to design the boundary — what does a program
actually need from the kernel, and how does it ask? Once that boundary is right,
the second app just uses it. The kernel got a few kilobytes smaller
again, and both games now sit cleanly on top of the same thin syscall layer, with
no game code left inside the kernel at all.
One ghost from 1981
There was exactly one snag, and it’s a lovely period detail. The game built
fine, but run asteroids.bin insisted the file didn’t exist —
even though I could see it on the disk.
The culprit was the filesystem. Rainbow-OS uses FAT12, the format from the
floppy-disk era, and its filenames follow the old 8.3 rule: up
to eight characters for the name, three for the extension. „asteroids“ is nine
characters. When the build tool copied the file in, it quietly created one of
those ASTERO~1.BIN mangled short-names that DOS used to paper over
long filenames — and Rainbow-OS’s deliberately minimal FAT driver, which
only speaks plain 8.3, went looking for ASTEROID.BIN and never found
the mangled alias. The fix was to name the binary something that fits:
asteroid.bin, eight characters exactly. A bug report that could have
been filed in 1985.
Where this is going
Two games down, and the road out of the kernel is paved. The bigger residents
— the text editor, the BASIC interpreter, the C compiler, the debugger
— are still built-in, and they’re a different kind of problem: they read and
write files, so they’ll need a file-I/O syscall layer before they can leave, and
some are too large for the OS’s own little compiler to build. But the pattern is
set. Each one that moves out makes the kernel a little smaller and a little more
like what a kernel should be: the thing that runs programs, not the thing that
is the programs.