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!
History
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:
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
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.
Users
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:
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.
Very nice overview – sad that I’ve never had a chance to see one of these running.
I always wondered where the ARM cpu came from…
“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!”
Some of the first ARM chips were used in a second processor add-on for the Beeb but this was not the main reason for the creation of the ARM chip.
” [the Arc] It had a graphical user interface – the second to appear for public consumption (Apple’s Lisa got there first).”
There were a few comercially available GUI interfaces before Arthur/RISCOS: MacOS, Amiga OS, TOS, etc.
“Different machines may come with support for different filing systems, and in theory users can write their own.”
Programers can write them, not users.
“Better to use a taskwindow, which gives a command line in a window.”
There can’t be many OSes that don’t have this feature.
“To save an object to a directory you must open the directory’s window and drag the object’s icon inside.”
True, one of the most missed features of RO on other OSes for me.
“Files in filing systems have a filetype.”
Agreed, another great feature.
“There are two sorts of directory. Plain directories and applications.”
More great features.
“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.”
The machine boots from ROM, you don’t even need a HD.
” The 77 file limit is long gone, but you cannot help admiring Acorn’s chutzpah.”
A limitation that could be worked around in the era of floppy disks and 20meg HDs but one that became tiresome beyond that era.
Programers can write them, not users.
When I sit down to write some code I am a programmer, when I sit down to read my email I am a user.
When I sit down to write some code I am a programmer, when I sit down to read my email I am a user.
When you sit down to write a new filing system, you are which?
Both, of course. Just because you’re not an average user once you start writing code doesn’t suddenly not make you a user: being a user is a continuous property. Just because you stop using your computer at night doesn’t somehow negate the fact that you are a computer user, for example.
That was my point. All programmers are users but not all users are programmers. The statement “in theory users can write their own” implies that non-programmers can create file systems. To me, that’s what it sugests anyway.
I’d be happy with the statement, “Users can create their own icons”.
“Programmers can create their own file systems” is a truer, less abigious statement.
I would like to respectfully disagree sir. If you create an icon you are clearly an artist.
“To save an object to a directory you must open the directory’s window and drag the object’s icon inside.”
True, one of the most missed features of RO on other OSes for me.
Available on Linux too:
http://rox.sourceforge.net/desktop/about_rox
There’s even a freedesktop.org spec for it:
http://freedesktop.org/wiki/Standards_2fdirect_2dsave
Now, if only more applications supported it…
Other RISC OS type features from the article available with ROX include:
– Application directories (except for !Boot, which is a security risk in today’s networked / multi-user world).
– Popup menus without menu bars.
– Icon bar (not quite the same, but used in a similar way).
– Filetypes (MIME types stored in extended attributes).
One thing that really stands out in RISC OS though is the simplicity of the whole system. Everything about the way it works is simple to understand, and you really can know what every single file on your system does.
The knowledge that even if you wipe the entire drive, your system will still boot and be usage is great too, although that’s more a feature of the way the OS is delivered (in ROM) than the OS itself.
“The knowledge that even if you wipe the entire drive, your system will still boot and be usage is great too, although that’s more a feature of the way the OS is delivered (in ROM) than the OS itself.”
I think it would be fair to say that this is also a feature of the OS. Writing an OS that loads from ROM is different from writing an OS that runs from ROM. The latter requires a clear separation between the code space and the memory that the code uses, along with an architecture that allows it. Perhaps I’m over emphasising this a little, but RISC OS certainly had to be designed specifically to allow it to run from ROM.
I think it would be fair to say that this is also a feature of the OS. Writing an OS that loads from ROM is different from writing an OS that runs from ROM. The latter requires a clear separation between the code space and the memory that the code uses, along with an architecture that allows it. Perhaps I’m over emphasising this a little, but RISC OS certainly had to be designed specifically to allow it to run from ROM.
I think all modern operating systems do that, though. Remember that most use disk caching to load programs: code pages are mapped directly to (read-only) pages in the disk cache. This saves memory, allows code to be shared between programs, and makes things faster. If you allow writing to code areas, everything gets much less efficient as the whole page of memory, including the unchanging code, has to be copied.
Still, you might want to code from ROM to a read-only RAM area anyway, depending on whether RAM access is faster and how much free RAM you have.
Whilst this is an introduction to RISC OS (an OS I used as a school child), it fails to mention Arthur, the OS that came before RISC OS. http://www.guidebookgallery.org/timelines/riscos
RISC OS itself was not released until 1989. Before that the original Mac OS, Windows, GEM and GEOS were already around, not making RISC OS the second GUI for public consumption as claimed.
I like the detailed coverage of RISC OS’s application structure, as it is similar to how OS X functions, utilizing folders as applications.
The author is also using a custom OS X like skin for his machine. I’m personally in disfavour of demonstrating an OS with a highly customised space as it does not show the OS in the correct timeframe, somewhat stealing from the magic.
Overall, this is a nice and passionate review, but doesn’t “name some names” enough, regards comparisns. (For example, the classic Mac OS finder is similar to RISC OS’s filer in that they are both spatial, not allowing you to open two windows of the same directory.
It does mention Arthur!
http://www.guidebookgallery.org/guis/riscos/riscos1
Oopsie, my bad! You ment the one on this site, not the other one, sorry, got confuzed!
IIRC ArthurOS was a program written in (BBC) BASIC. (NOT COMPILED!)
I like some of the ideas in this OS. Many of these are clear signs of going forward. If not the implementation, then at least the concepts. The part about commands within an executable are especially good.
Although not as visual, I still miss this feature on the AmigaOS where most applications would publish an API in the application itself that provided ALL of the application’s functionality. So you could use applications just like libraries and build larger applications. I never understood the need to separate dll’s and COM objects from the executable if the executable can provide that functionality directly. Using apps as dll’s OH NO!!! We can’t do that. I miss it.
I liked this piece. Here in The Netherlands the Acorn computers had (and have) a small but devoted group of users. I never owned an Acorn myself, but I have seen the RiscOs in action – very fast, very fluid, very interconnected. A pity quality of this kind goes unrewarded in a very competitive market.
Yes, I’ve seen one in action too some 8 years ago.
What I remember most clearly, is that when he had a lot of windows open which needed to be closed, he would just reboot because it was faster than him closing all windows manually. And that was with a machine that booted relatively slowly, because he had some harware add-ons (like the network interface, I’m not sure if the SCSI was standard). Shutdown took about 1 second, bootup a whopping 3.
Also very nifty was the addon card with a 486 processor on it. It allowed him to run Windows95 at full speed inside a RiscOS window. I’m not sure if the likes of VMware were already around at the time, but I found it very astonishing at the time.
Edited 2006-07-06 09:27
not bad at all. nice piece. Would of liked to seen/read more about usage and day in and day out kind of stuff but all in all a good intro… better than I could probably do
“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.”
This totally sums it up for me. Despite the massive advances made by other OSes over the years, I still find myself returning to RISC OS every time. And it’s not just that you can access the innards of the OS and change them that makes you feel in control, it’s also the design of the GUI.
Obviously I’m biased, but I thought this was a great article
Edited 2006-07-06 10:06
But I have to comment the history bit was a bit confusing if you didn’t already know the background. And as some pointed out, it was more confusing if you in fact do know the background
The article is a nice overview of features that are missed in other OSes, covering a number that I missed in previous articles on the subject on drobe. Too bad RO is still cooperative multitasking. It’s what, in my opinion, takes away the ‘still ahead of it’s time’ feeling (similar to lack of memory protection in Amiga OS).
Great article! Awesome! It’s nice to see more about RISC OS.
I have been using RISC OS for, well since it started (I was 5 at the time)
I now use it in a Windows Environment Office.
It has saved me many times, when my Laptop has died of one virus or another.
Because of the lack of viruses that attack it, I can have full Internet Access :@) so no firewall, which means most people use my RiscPC SA (12 years old) to surf sites that are usually blocked / open up archives.
I am an IT Administrator at my company, and use it regularly as a DTP, Network Diagram, and Remote Desktop terminal., infact I am writting this from it!
It logs into our domain shares / e-mail by just switchigg it on, and using the new user login system (RISC OS Adjust).
It impresses all whom I work with :@)
Oh I also run a web server from it, to host a few sites :@)
I remember getting told by a Microsoft engineer that once he walked into Bill Gates office, there was a Archimedes 310 machine and Bill Gates was examining the RISCOS machine in his office. Seemingly Mr Gates loved the Icon bar.
This was a horizontal strip on the bottom of the desktop where all the applications sat.
He told my friend, that he was going to copy this feature for the release of Windows 95…
Cute.
I remeber Sophie Wilson, one of the key developers of the ARM chip, telling me that one of the requirements of this new RISC chip was that they wanted it running BBC BASIC as fast as 6502 machine code.
They got their way too… 🙂