So you thought you would find here an impartial, knowledgeable comparison of RISC OS with the more popular and better known operating systems? Think again; I have been so steeped in RISC OS, since even before its appearance two decades ago, were that possible, and I am so ignorant of other operating systems, that I cannot honestly deliver to you a balanced picture. Well, that is the modern usage of apology over with, so let us get on to the older sense. Note: This is the 2nd entry to our Alternative OS Contest which runs through 14th July!
In the late 1970s Acorn (http://www.mcmordie.co.uk/acornhistory/acornhistory.shtml) was a small company in Cambridge, UK, producing electronic equipment for laboratories. My first microcomputer was an Acorn Atom, produced in 1980 with 2K of RAM, using a 6502 CPU. Acorn went on to win the BBC’s commission for a microcomputer to be used in UK schools as part of an educational series of broadcasts. Its success with the resulting BBC B microcomputer made the company a household name in the UK. This machine was designed to be usable as a front end to more powerful second processors. However, Acorn found that all the currently available CPUs, from Motorola, National Semiconductor, Intel and Texas Instruments, were simply not fast enough at handling interrupts to work satisfactorily in this role. So they decided to manufacture their own! Thus was born, in 1986, the ARM (Acorn Risc Machine) CPU architecture. The Acorn Archimedes was the first microcomputer in the world for public sale to use a RISC (Reduced Instruction Set Computer) design. Its new operating system, RISC OS, was designed specifically for the ARM CPU.
This history is important, because it was to set the design-parameters for RISC OS. Acorn was selling to teachers and schoolchildren, and academics. The Archimedes could not be too expensive, and it had to be easy to use. This meant compromise. A cut-down multi-user OS, or a converted business system was not appropriate. RISC OS was a clean sheet design, for a personal, single-user microcomputer. It had a graphical user interface – the second to appear for public consumption (Apple’s Lisa got there first). In fact the window manager was also the task manager, so the GUI was no bolt-on extra. Considerable effort went into making it easy to use and consistent. If this catered for the inexpert, the geek was kept happy too. RISC OS consists of an expandable cluster of modules (what an overloaded word); software packages in ROM or loaded into RAM. If you do not like some feature of RISC OS, well then, unplug the relevant module and substitute your own. Writing modules is not completely straightforward, but the excellent programmer’s reference manuals (PRMs) have made it possible for many third party modules to be written. In a word, RISC OS has been designed to be totally under the user’s control, like a motorcycle that can be dismantled and put together again on the kitchen floor. This feeling, that what is in the machine is the user’s, not some piece of magic graciously licensed by a distant authority, goes a long way toward explaining why RISC OS users remain so.
The decision to provide RISC OS in ROM may well have been influenced by its use in schools. Early models of the Archimedes were usable with half a megabyte of RAM and no hard disc, GUI and all. ROMming the OS has big advantages for security. The only disadvantage is when you need to update; modern RISC OS hardware lets you reflash the ROMs when you are safely disconnected from the internet.
Remember the 640K limit on RAM that IBM machines once had? Well Acorn suffered a similar blindness when gazing into the crystal ball. The ARM chips up to and including version 3 used a cunning ruse to save memory and gain speed. All the registers in an ARM CPU are 32 bits wide. Those early versions used a 26-bit address bus (giving a 64Mb limit to the address space) and used the 8 extra bits in register R15 (the program counter) as status flags. This meant that both program counter and status flags could be saved by storing a single register. RISC OS was initially designed around this trick, alas. When the hugely successful ARM Holdings was spun off from Acorn and Acorn broken up to make this possible, new ARM designs appeared with a separate status register to cope with proper 32 bit addressing. The ARM 6 and 7, and Digital’s brilliant StrongARM chip all had 26-bit compatibility modes, so RISC OS, which lived on under a sort of user buy-out, could and did use these chips. But the writing was on the wall. Why should ARM chip manufacturers bother with providing a compatibility mode for the small numbers of users of an obscure operating system? RISC OS had to be rewritten for 32-bit compatibility if it were to take advantage of newer ARM CPUs, a daunting undertaking for a small business. My own computer uses an XScale CPU and a 32-bit version of RISC OS.
RISC OS Filing Systems
RISC OS does have a command line, but it is so vestigial that most users are probably unaware of its existence. Better to use a taskwindow, which gives a command line in a window. The RISC OS desktop provides an iconbar along the bottom of the screen. At the right hand end sit the icons of running tasks, and at the left the icons of filing systems. Its purpose is to provide permanent access to basic facilities when there are no windows open.
[Note about pictures: some icons are provided as standard: desktop furniture, icons for filing systems or filetypes, etc. However, they can all be replaced by the user’s own designs, so two users’ screenshots may well appear totally different.]
Filing system is an important RISC OS abstraction. Different machines may come with support for different filing systems, and in theory users can write their own. Various modules are provided which provide the basic services that a filing system may require, so that filing operations (loading, saving, renaming etc) present a uniform drag-and-drop aspect to the user. Above you see icons denoting filing systems for:
- Hard disc
- Shared discs on my LAN
- The memory stick I have just stuck into a USB port
- The Resources read-only drive
- Memphis, a third party RAM drive
- SparkFS, a third party archiving system
A file’s full pathname must contain a prefix that specifies which filing system it belongs to.
RISC OS mice have three buttons. The middle one is used exclusively for popping up a context sensitive menu. No jumbo-jet-cockpit clutter of drop-down menu icons. Window real estate is too precious for that. The left button is used for selecting items or initiating actions. The right one is used for adjusting selections or for performing operations inverse to those of the left button. These are matters of convention, for the most part. Drag a window with the left button and it will pop to the front and move over the top of other windows. Drag it with the right button and it will move at its own level in the window stack, behind windows that are further to the front. Clicking in a text window to give it the input focus does NOT move it to the front of the window stack; click on the text window’s titlebar to do that. These are just a couple of ways, out of hundreds, in which the RISC OS desktop differs from those of other operating systems.
A very important aspect of the RISC OS desktop is the consistency of its visual metaphor. A filer window depicts the contents of a directory. The icons in the window depict files or subdirectories. To save an object to a directory you must open the directory’s window and drag the object’s icon inside. This way of doing things (as opposed to dragging objects onto icons) has two advantages: first, a directory window is a target harder to miss than an icon, and second, you get visual confirmation of a successful save by seeing the object’s icon appear in the window. You cannot open two windows onto the same directory. That would break the metaphor. For saving data, an application will pop up a dialog box with an icon, which you then drag into a directory window. The filer is like the ocean – all desktop applications swim in it – they do not have to provide their own depictions of where files are. The desktop itself is the representation of the filer. This gives the most radical difference in feel from other operating systems. The screen is there to provide space for the user to read information, so you may need lots of windows open simultaneously. Applications in RISC OS are supposed to cooperate with each other, and taking over the whole screen, or changing the graphics mode is rude, selfish behaviour. I wonder if there is a thesis waiting there – Social paradigms in operating systems?
Applications and Filetypes
Files in filing systems have a filetype. This is 12 bits of data that play much the same role as a filename extender in other operating systems but which in RISC OS are not part of a file’s name. The icon used to depict a file in a directory window depends only on filetype. Some filetypes are provided as standard, others can be user defined. You can always change the filetype if convenient.
There are two sorts of directory. Plain directories and applications. An application is distinguished from a plain directory first of all by having a name starting with ! . It also differs in appearance and in what happens when you click on it. With a plain directory, clicking on it will open its window, with the left button leaving open the window it resides in, but with the right button closing the window it resides in (so if you want to travel down the directory hierarchy without cluttering the screen, use the right button). With an application, however, clicking on its icon will run it. You can open an application as if it were a plain directory by holding down a shift key when you click on it.
Applications are one of RISC OS’s secret weapons. Every application should or may contain files called
Obey files contain textual commands, which are executed when you click on the file’s icon. Clicking on an application has the same effect as clicking on its !Run file which, like !Boot, is generally an Obey file.
The !Boot file is run once, when the directory containing the application first has its window opened. This allows the application to carry out some initialization. When this happens RISC OS first of all sets a variable Obey$Dir to the full pathname of the directory or application containing the Obey file. Usually the first command in the !Boot file will be to set another variable to the value of Obey$Dir, so that the application knows where it is, before it goes on to do things.
If a file called !Help is found in the application, then RISC OS will add a Help item to the pop-up menu of the application. Selecting the item has the same effect as clicking on the !Help file.
The appearance of the application is determined by a sprite (a native bitmap format) of the same name as the application in a spritefile called !Sprites. An application called !Paint is provided for the user to create her own sprites.
The point of all this is that an application is a complete package that can be put anywhere you like in the filing system. By setting a variable it can tell other applications where it is. When you want to get rid of an application, just delete it. No fancy de-installers needed. If you need to boot the computer from a filing system then you need an application in its root directory called !Boot, whose structure is mostly mandated. But apart from that, the user can organize a filing system any way she wants. In fact I sometimes shock Windows users by telling them that of the 7Gb of files on my hard disc I reckon to know what each one is for, and I reckon to be able to spot cuckoos in the nest by eye. Could they do that? A slight exaggeration perhaps, but a reasonable claim.
Early versions of RISC OS would not let you put more than 77 files into a directory. I am not sure of the real technical reason, but an excuse sometimes given was that you are not likely to be able to keep track of more than 77 heterogeneous objects; and if they are homogeneous a directory is probably a daft way of organizing them anyway. The 77 file limit is long gone, but you cannot help admiring Acorn’s chutzpah.
Multitasking of user tasks is cooperative, not preemptive. That means that a badly written task can hang the system. Yes, total control means no security. It also means that writing programs that create tasks is more complicated.
When you click on an object’s icon in a filer window, the filer broadcasts a message to all tasks that have registered to receive such messages, notifying them what the object’s pathname and filetype are, and where on the screen its icon is. If a task recognizes the object as one it should do something about, it acknowledges the message (so the message is sent no further) and has its way with it. If no task recognizes it, the filer looks at the object’s filetype to see if that specifies a run-action. In the case of HTML files, for example, it will say, fire up a browser and put my pathname on its command line. If no run-action is specified then the user is informed of that. Run-actions for standard filetypes are set up at bootup, but all such run-actions can be redefined by the user.
Enough about the operating system; what about the users of it? There are not enough of them to keep programmers tanked up with coffee, that is for sure. But there are advantages to being a member of an obscure and aging minority. People help each other. If you have a problem, send an email to a user group and the solution can come back in minutes. No worry about viruses; no Trojan horses. There is a lot of very good software that is either free or very cheap. The free text editors Zap and StrongED are amazing. Techwriter, a structured document editor originally commissioned for Apple, is wonderful. I am writing this now with it. It can save my document out as:
- Draw, a native vector graphics format
- TechWriter – its own format
The fish in a shrinking pool tend to bite each other, but you soon learn to avoid those that do. I have said nothing about using RISC OS with music (e.g. Sibelius), video production or graphic design. The range of uses to which the RISC OS community puts its machines is far wider and more diverse than I can hope to describe.
Being non-standard has lots of drawbacks but none yet so compelling that I must use another operating system.