When working on software that must run under RISC OS, there are many issues that you must keep in mind that might not be obvious or apparent to people who have never written software for RISC OS before. This page describes some of them.

Some of the NetSurf Project's sponsors have donated us the equipment and bandwidth required to give accepted students access to an open-access RISC OS computer over the internet, so they can test and experiment with it. This is done via an IP KVM using a rather ghastly, but usable, Java applet in a web page. The machine is an A9 Home donated by Advantage Six Ltd.

RISC OS is co-operatively multi-tasked

RISC OS GUI applications must 'yield' to the OS before another process can be scheduled. This is done via the Wimp_Poll system call. In NetSurf, this is wrapped inside gui_multitask(), which handles yielding to the OS, getting GUI events from it, and running scheduled functions.

RISC OS has a limited number of shared-namespace file descriptors

RISC OS has 255 file handles - and that's it. You can't possibly have more files than that open at anyone time, and there is a single pool of file handles shared by all processes. Don't leave files open that you don't need to keep open, and don't blindly close other handles.

RISC OS has a limited number of shared-namespace socket descriptors

Unlike on other operating systems, RISC OS's sockets are allocated from a different pool of numbers. They may, for example, overlap with file descriptors. Also note that as with file descriptors, there is a single pool of them shared by all processes. There's also a limit on the number you can have open at once. This can be as low as 64.

RISC OS's environment variables are global to the system

RISC OS uses environment variables extensively: much of the configuration of the system is done via them. They are shared by all processes. Because of this, RISC OS has a naming convention for them so they don't clash. If you really feel the need to use an environment variable, you should prefix its name with NetSurf\$.

Memory is valuable

RISC OS machines may have as little as 64MB of RAM, and the OS provides no support for swap or paging. Additionally, much of the memory allocated via malloc() will end up being allocated in what is called a Dynamic Area. The upshot of this is that if you fragment the heap too much, you've basically wasted memory, and no process will be able to use the spaces you have freed.

RISC OS hardware is slow

The fastest RISC OS computer you can buy is a 600MHz ARM clone with no floating point and a tiny cache. Make sure your code is tight, but remember readability and maintenability is paramount!

RISC OS is delicate and lacks wide-spread memory protection

It's trivial to take down the entire OS if you're not careful, where on other OSes you'd just get a SIGSEGV. Be careful!

RISC OS lacks shared libraries

While the GTK version of NetSurf's binary is less than 600kB, RISC OS has no shared libraries, meaning it's over 3MB. Given the speed of RISC OS machines, this is already a problem. If you want to make use of a new library, make sure it's not too huge, and that it doesn't depend on a dozen other libraries.