The Icon Bar
Upon launching, a RISC OS application adds itself to the application bar (or the 'icon bar' in RISCOS-speak) at the bottom of the screen. Typically, a RISCOS application, when first run, does not open a blank document. If the user would like to start a new document, he or she clicks once on the icon in the icon bar. If the user would like to open an existing document, the user can either, double-click on the document, or drop the document on the icon bar icon. If the user would like to open a .html file in the text editor, the user simply drops the file onto the icon bar icon that represents the text editor.
RISCOS convention dictates that hardware devices such as printers and hard disk drives are placed on the left of the icon bar and applications to the right.
Drag And Drop Saving
On RISCOS, the drag and drop concept is carried over to the saving of files; there is no conventional file save dialogue. The 'save file...' option exists as an entry on the main pop-up menu of the application. To save a file, the user first navigates, using the standard file management features of the OS, to the intended destination directory for the file; then, the user, navigates to the save menu, edits the file name and then drops the file into the directory. This usage pattern makes sense from a usability point of view. Often when a user is working on a file, he will already have a file management window open on the desired directory. Further more, the user will often want to operate on other files within that directory.
Drag and drop even works between applications. Having selected some text, a user can import the text into another application by dragging the icon in the 'save selection...' menu from one application to another. Where applicable, and supported, the applications can establish an OLE link rather than simply transfer the data.
Nearly all of the OS is implemented as a collection of 'relocatable modules'. These modules extend the kernel with extra system calls and these functions become available to all user and system programs. As the entire OS is implemented in this way, it is quite simple to upgrade a section of the OS or to add new functions. To upgrade the font system, for example, the user loads the new font module from disk. If the module in question is an upgrade to a module in the ROM, the newer module takes precedence. RMs can be launched at run time from a start-up script, as part of an application launch script, or by the user at any time.
The floating point maths module is an example of an RM. If an application requires FP capability, it ensures that the FP module is loaded. Every time the ARM Microprocessor encounters an unknown instruction it offers the instruction to any co-processor that is present. If no co-processor can handle the instruction, the CPU generates a software exception. In the case of a FP instruction, the software FP module intercepts these exceptions, implements the operation using integer operations and returns a result. When a new version of the FP module is released, the user adds it to his '!System' folder so that all applications can invoke it when needed.
Most of the OS outside of the kernel is implemented in the form of RMs. Even though much of the OS can be soft loaded in this manner, all shipping machines can at least get as far as the desktop in a machine without a hard drive attached.
Compared to other desktop operating systems, RISCOS is very compact and efficient. It doesn't have a system-wide virtual memory disk-paging system and consequently, all apps are designed to fit into RAM. And on the whole, they manage this very well. In cases where data would be unable to fit into RAM, the applications themselves have to implement their own disk paging system for the data.
Obviously, a 50meg TIFF file takes up 50 megs of RAM on RISCOS machine just like it would on any other machine but on the whole, applications are tiny in terms of memory footprint.
Some of the superior compactness and efficiency of RISCOS compared to other operating systems is the result of technical aspects of the operating system but much of it comes from the, less tangible fact, of the 'RISCOS mindset' in that a 'culture of anti-bloat' pervades on RISC OS.