posted by Michael Reed on Thu 7th Dec 2006 12:07 UTC

"Part I: RISC OS Features"

Part 1 - Some Of The Features Of RISCOS - for the uninitiated.

Multi Tasking

The method of multi-tasking that RISCOS uses is called co-operative multi-tasking. In such a system, the main program loop of each running application progresses through a sequence of functions such as checking for user input, refreshing parts of its display and performing performing any processing on its own data. The last function in this sequence is always to return control to the OS. Having regained control, the OS then services the next application.

If you were to run:

10 PRINT ``hello world!''

20 GOTO 10

on a RISC OS machine, the entire gui would stop until the application had finished or the user terminated it by pressing . If an app crashes, and gets stuck, there is the possibility that the OS will never regain control. In such a situation the whole system crashes.

In contrast, other operating systems such as Microsoft Windows and AmigaOS instead employ pre-emptive multi-tasking. Under such a system the execution of such a perpetual 'hello world' program, would leave the rest of the system unaffected.

Another problem inherent to co-operative multi-tasking is that, as each app has to finish what it is doing before it can return control to the rest of the OS, multi-tasking is not as smooth as it is on other OSes. Sometimes, a programmer knows, in advance, that the application will need a lot of time for processing. In such a case, on a co-op system, the programmer can split the task up into manageable sections so that the program can periodically relinquish control to the OS so that other apps can be serviced.

For example, an application engaged in a task of image processing that will take 30 seconds to complete, won't necessarily tie the entire machine up for thirty seconds; one would hope that the programmer would have found a way to split the task up into chunks. However, this is not always the case and this means that, in cases of normal application usage, the hourglass pointer can be system-wide. On other operating systems, one wouldn't normally expect to be confronted with a system-wide hour glass. If, for instance, an application such as The Gimp presents one with an hour glass, on other operating systems, it would be expected that one could switch to another application while the processing is in progress.

It is actually possible, under RISC OS, to implement processes that run as a 'background task' in that they are seemingly un-interuptable processes that do not ostensibly appear to be disrupting other tasks on the machine. A music player would be an example of an application that uses this technique: When the system is in use, user application activity must not interrupt the playback of the music. Most applications of this sort split their functions between an event-driven module (see section on RMs, below) and a WIMP driven front end that controls the player module. The relocatable module operates independently, doing the actual sound processing and periodically filling the sound buffer. At times, the WIMP front end might appear to be interrupted, the counter could stop, but the music will keep playing.

Memory Protection

RISC OS doesn't employ much in the way of memory protection. A crashing app can overwrite the workspace of another app or even of the operating system itself.

This lack of memory protection also makes the OS inherently insecure. Any app could, in theory, look within or alter the workspace of any other application. To people shuddering at this point: hold on to your tin-foil hat, it's not as bad as it seems! Any exploit that takes advantage of these weaknesses must be coded specifically for RISCOS and as with other alternative OSes, RISCOS simply doesn't have much of a problem with spyware, trojans or viruses. In truth, RISC OS would have to become about 100 times as popular as it is now before these problems became manifest. Even then, a ploy of some kind has to be successfully carried out in order to get an executable onto the machine.

In summary, by the time that RISCOS had gained an entire percentage of the web access statistics, something could be done to improve security. Something tells me that an IE equipped Windows box is going to suffer greater security problems than the average RISCOS user.

Table of contents
  1. "Introduction"
  2. "Part I: RISC OS Features"
  3. "Part I: RISC OS Features, Continued"
  4. "Part I: The OS Split; Hardware"
  5. "Part I: Hardware, Continued; Emulation"
  6. "Part II: Barriers to Adoption"
  7. "Part III: What Would It Take to Drag Me Back?"
  8. "Part III: PDA Port of RISC OS"
e p (5)    58 Comment(s)

Technology White Papers

See More