A Fun OS to Learn About OS's

Rather than talking about some feature that RISC OS doesn’t have yet, I wanted to post something positive and complimentary about the OS experience itself, and where I think it could be useful as a teaching OS.

I was heavily influenced as a kid by owning an Amiga and also having been loaned/given (since I forgot to give it back; sorry, Jim!) a copy of the first edition of the MINIX book. I didn’t have the $75 to buy a copy of the OS on disk, since it wasn’t open source at the time. There was a demo of the Amiga version available on one of the Fred Fish disks, and that intrigued me as well.

But the Amiga and Atari ST ports of MINIX fell into disrepair a long time ago. More to the point, while it seems like it ought to be very snappy, I never was impressed with the speed of using it. The message-passing really seemed to bog down I/O and multitasking in a way that I couldn’t explain, because it’s so fast to boot and the OS is so small.

RISC OS has its drawbacks in not having SMP yet or full preemption of apps and modules, but as compensation for those limits, everything feels very snappy and I enjoy it as a user very much.

The other retro OS I’ve been looking at this year is AROS, the open source clone of Amiga OS. Specifically, I’d like to try to port the m68k-amiga version (the only one that’s binary compatible with Amiga apps, as opposed to only source-code compatible) to run on QEMU’s emulated Mac Quadra 800, and then on the Foenix A2560K-040V, which has a whopping 25 MHz 68040V (MMU but no FPU). That’s going to be a very different challenge in terms of working within limitations.

AROS is written in C for portability, and since the source code’s available for both, from a learning/teaching standpoint, I think they’re both great choices to see how a real OS works from the bootloader forward, without getting bogged down in complexity at every step of the way.

The fact that so much of RISC OS is written in 32-bit ARM assembly has its issues going forward, as is well known, but it’s also been educational to read well-commented ARM assembly, and I find it more straightforward than m68k with its separate data and address register banks.

I wouldn’t be surprised if more people interested in learning how an entire OS works will discover and gravitate to RISC OS for any or all of these reasons. It’s a very unique experience, for sure.

RISC OS has its drawbacks in not having SMP yet or full preemption of apps

Fixed

The message-passing really seemed to bog down I/O and multitasking in a way that I couldn’t explain, because it’s so fast to boot and the OS is so small.

It’s been decades since I read the Minix book (thanks, Woking library), but if I remember it put pretty much everything into user space so things can be isolated from each other and from the kernel.

Depending on your processor and memory system, that could end up hurting as there will be a lot of context switches involved in getting anything working.

As the recent processor cache exploits have demonstrated, you can have security or you can have speed. Pick one.

RISC OS took the other approach, the one where every damn third party module starts up intermingled with kernel stuff (the mess that is the RMA) and with the same privileges. One single stupid stack imbalance in a big wodge of module assembler and the machine will stiff itself as the kernel can’t recover from it’s own stack getting messed up.

will discover and gravitate to RISC OS for any or all of these reasons

I think the number of people interested in doing stuff in assembler is rapidly diminishing. Sure, it’s a great example if you are interested in the low level stuff, but these days the big companies are promoting Rust since C/C++ is annoying and flawed, so what hope assembler?

I’ve got a Tannenbaum book from around 1984. I still think that doing most things in user mode is the way to go, and doesn’t have to be inefficient. At the very least, there shouldn’t be anything in the kernel that enables interrupts because it takes so long; pass it off to another user mode task and wait for the result.