RISC OS - the Acorn point of view

Acorn spent a great deal of effort on developing chip technology, and then
found itself with a wonderful hardware platform but no OS [the OS we were
developing, ARX, turned out to be late and not what was advertised - like it
wouldn't have worked in an A310]. As a consequence the Arthur project was
started: to produce a BBC-like OS that would be simple, and would provide
BBC-Computer customers with an upgrade path. This was avowedly single-task,
and had its basic IO structure inherited from the Beeb. The compiler
facilities were not in good shape when the project was started, and so it
was written in assembler. The module system grew from this as a
generalisation of the plug-in ROMs of the Beeb. The window and font managers
were added in order to make it all look a bit more interesting. Thus, Arthur
1.20 was born.

Arthur 2 (then to become RISC OS, of course) was then tied by (binary)
backwards compatibility both to the BBC, and to Arthur 1.20. There was
enormous pressure to improve the memory usage for single large applications
that take up all of a 1MB machine. All of the device drivers had been
written with single-tasking access in mind, and would need radical
restructuring in order to work in a multi-tasking way.

This, combined with resource limitations, meant that we were faced with a
choice during 1988: either rip out the guts and redo them all, or
concentrate on applications/end user considerations such as consistent user
interfaces. In the circumstances, I believe that we made the right decision
and that it has worked out extremely well.

Observe how similar this story is to the Mac! The main difference is that
Apple dared to start again entirely, and ditch all backwards compatibility:
they find it impossible to do this again, however. The Mac OS (like RISC OS)
has many imperfections when compared to traditional OS design, and yet
provides what users want in a friendly desktop computer.

So, what of the future? Use of RISC OS is growing steadily, as more users
realise that it offers a friendly user-interface, and as more applications
become available. We are working on further developments of the OS, but
there is not planned to be another major release for quite a while: what
major customers and applications developers need most now is a period of
stability.

Although the user is king, I find in general that most programmers like it
too: but C programmers really need 2MB and a hard disc in order to work
effectively.

Other random points:

I do not think it very important that the multi-tasking happens in the Wimp
rather than in the kernel: once the decision was made that multi-tasking is
not pre-emptive, the choice seems obvious. !Edit's task window allows
such things as large compilations to happen in background, and gives
sufficient pre-emptiveness to be useful in many areas.

Yes, it would be nice if the Task display were not necessary. I notice that
the Mac's prototype outline font managers have a control panel entry to vary
its size... as a general rule this seems the most common cause of having to
venture up to the Task display. The MultiFinder also has a similar display
(though less powerful), as did Tripos (proto-AmigaDOS) when I used it.