Relation to RISC OS

What's RISC OS?

RISC OS is an operating system used in Acorn/Castle machines. It had some good GUI features, but was poor in other areas. ROX seeks to bring these good UI features to Unix-type platforms.

Can I run RISC OS apps within ROX?

No - ROX is not an emulator, it's just another Unix desktop. RISC OS applications need to be ported to run under ROX (at least until riscose gets good enough to run graphical applications). You can, however, run a RISC OS desktop in a window using an emulator such as ArcEm.

Why did you not implement the back icon as part of the window furniture when you designed ROX?

Under X, you can choose to run any window manager with any desktop. Many of the screenshots show the xfwm4 or OroboROX window managers in a more-or-less default configuration. In this, clicking the middle mouse button anywhere on the window frame will send a window to the back. Other window managers may offer an explicit back button, or you can configure them to have one.

How can I make ROX even more like RISC OS?

There are several things you can do:

• Open ROX-Filer's Options box (by choosing `Options...' from the menu)
  and turn on all the `(RISC OS Style)' options.
• You can use xfwm4 as your window manager to get the RISC OS behaviour of using the right mouse button to move or resize windows without bringing them to the front. Set the 'raise_on_click' option to 'false' too.
• You can get Adjust-reverse-scrolling by applying this patch (might need a little tweaking now).
• There are various RISC OS themes around, including Andrew Flegg's RISC OS theme (for IceWM and Gtk) and Peter Howkins's sawfish theme.

Take a look at this screenshot:

Isn't pre-emptive multitasking slow?

On RISC OS (eg, using a task window or wimp2), yes. On systems designed for it, like Linux, it actually makes the system faster and more responsive.

• Multitasking is used when you have more runnable processes than CPUs. Most systems only have 1 CPU.
• A runnable process is one which wants to use the CPU (not just a program which is loaded but doing nothing).
• Most of the time, nothing is runnable (the computer is waiting for you to do something). In that case, it doesn't matter which system is used.
• Most of the rest of the time, exactly one process is runnable (eg, when you press a key your word processor needs to run to insert the character). When only one process is runnable, it doesn't matter which system is used. The one runnable process is always chosen.
• The only time the type of multi-tasking makes any difference at all is when you have several programs all trying to do things at once (eg, printing, rendering an image and checking your email).

In the rare case when you have several runnable processes, the type of multi-tasking matters. Cooperative systems (like RISC OS) run one process, and won't let any other process run until that one says it's OK. Preemptive systems (like Linux) can switch between runnable processes whenever they please. RISC OS users will note that the case of, say, formatting a floppy, printing a document and checking your email is a situation where RISC OS performs poorly (the system becomes unresponsive). Linux does not become less responsive in this situation.

Another effect of the RISC OS system is that processes using some resource other than the CPU can still prevent others from running, because a process can't do something and tell the system to run another process at the same time. This doesn't happen on Linux.

Here's an example of what happens on RISC OS:

• The floppy disk formatting program tries to write to the disk. Floppies are slow, so this takes a while.
• The user presses a key. The keypress is queued for later.
• After a second or so, the write operation completes. The floppy program wants to write another block to disk, but to be nice, it gives up control in case anything else needs to be done.
• The text editor runs, inserts the character and redraws the screen. The floppy disk is idle while this happens.
• The formatter runs again, and starts writing the next block.

The same thing on Linux:

• The floppy disk formatting program tries to write to the disk. Floppies are slow, so this takes a while.
• The user presses a key. Since the formatter doesn't need the CPU, and PMT systems can switch processes whenever they please, Linux switches to the text editor without any delay.
• The text editor inserts the character and redraws the screen while the block is written to the disk.

Can't RISC OS be made to do preemptive multi-tasking?

Although it can do it in a limited form, fast and reliable support requires the whole system to be designed with this in mind.
Consider something as simple as redrawing a window. On RISC OS:

• The system asks Edit to redraw window number 5, for example.
• Edit gets the size and location of the region to be redrawn (100x100 in the centre of the screen).
• Edit asks the system to draw the contents in the middle of the screen.

On a system which can switch between processes at any point in time, the user might open another window, or move Edit's window, between Edit finding its location and doing the drawing. Then the drawing would appear in the wrong place, or over another window!

On Linux:

• The system asks Edit to redraw window number 5.
• Edit gets the size and location of the region to be redrawn (100x100 in the centre of window 5).
• Edit asks the system to draw the contents in the middle of window 5.

Notice that if Edit's window is moved or covered then the final drawing operation is still correct, because the drawing is done relative to a window, not to the screen. It's little changes like this that are needed throughout the system. As another example, consider the case of loading a file. On RISC OS:

• Edit gets the size of the file (1Mb).
• Edit allocates 1Mb of memory at address 0xc000.
• Edit asks the system to load the file at address 0xc000.

On Linux:

• Edit gets the size of the file (1Mb).
• Edit allocates 1Mb of memory at address 0xc000.
• Edit asks the system to load the first 1Mb of the file at address 0xc000.

Because the file (perhaps a log file) may grow in size between Edit checking the size and Edit loading it, the size must be passed to the load operation to avoid overwriting other memory and crashing. Linux therefore does not provide any system call to 'load a whole file'.

Of course, RISC OS's lack of PMT also means it can't easily support machines with multiple processors, and it may be unreliable when using network filesystems (a remote log file can still grow).

Why not replace X with a new graphics system?

Because there's no point. X has a few problems, but they're not the things people usually blame on it. X is a graphics system that works on a huge range of graphics cards (laptops, desktops, mobile devices), has excellent backwards compatibility (decade-old software still works with modern X servers), 3D acceleration (for some cards) and support from many hardware vendors. X's policy is to have no policy about style (e.g., what a menu should look like, or which side of the window the scroll bar goes on). People therefore like to blame X for the fact that there are several different interface styles used on X (ROX, GNOME, KDE, etc).

When people suggest replacing X, they don't really want to replace X. They want to force people to use their preferred interface style by hard-coding it into the graphics system. In fact, this would just lead to people creating new graphics systems, one for each interface (after which everyone would complain that they couldn't run ROX applications under KDE's new graphics system, or that they couldn't run firefox under ROX, etc). In fact, the reason X is still here (and the older graphics systems aren't) is probably because it didn't enforce policy. Amusingly, after proposing that differing interface styles be made impossible by replacing X, there is then the problem that many useful X applications won't be available on the new system. No problem; the plans for the new graphics system gain an X-emulation layer. And we're back where we started...