Some of the good features of RISC OS include (just the basics):

• Simple to use Windowing System : ---
• Good Spacial Filer : ---
• Omnipervasive Drag and Drop : ---
• The Application Directory : ---
• The IconBar : ---
• Very Powerful CLI : ---
• Understandable API : ---
• Builtin BASIC V with Builtin Assembler : ---
• Runs on the ARM CPU : ---
• Great Stream Output (VDU) : ---
• Modular : ---
• Just Enough Memory Protection : ---
• Well Designed Cooperative Multitasking : ---
• Stays out of Way : ---
• Great Sound System : ---
• File Systems (Volume Oriented) : ---
• Image File Systems : ---
• Fun to Program for : ---
• Great Raster Graphics system (OS_SpriteOp) : ---
• Extreme Vecotor Graphics Support : ---
• Good Base Set of Applications : ---
• Powerful Object Code Debugging, builtin to the system : ---
• Does not put Limits on Anything : ---
• Very well suited to emulation : --
• Much More : ---

The Desktop is the combination of a few programs that provide the default RISC OS Desktop Environment. The Pinboard provides a backdrop, the IconBar is the first Dock / Taskbar type system in any OS, the TaskManager provides information on tasks running, and the Display Manager is a quick way of temporarily setting the screen resolution and color depth. There are also some filers that are running in the desktop, depending on the available filesystems.

By composing the Desktop of these applications everything is kept simple, easy to understand, and easy to use. The level of simplicity of each component makes the total system more robust.

The Desktop Environment provides for extremely pervasive Drag and Drop, that simplifies and improves workflow, way beyond what any other system provides for Drag and Drop. This makes it possible to keep all programs simple, while providing for a very robust total work environment (way beyond the huge multifunction programs used to do the same on other Operating Systems).

The Window Manager, known simply as the WIMP, is a very simple and powerful Window Manager. It provides for simple Windowing operations with dynamic focus, all menus are pop-up in place (thus no need to find the menubar), and live redrawing of windows being moved, resized, or otherwise altered.

The API of the WIMP is very easy to understand and work with, being possible to write a full blown, done correctly, windowing program in as little as 300 bytes (in hand coded Assembly Language). Do to the simple API working with Windowing applications even in assembly and BASIC is very simple to accomplish.

Filers provide the directory displays for the filesystems mounted at a given time. Most filers are instances of the core filer, thus providing a known set of features, just with different filesystems. The windows provided by filers are also targets to drag a file Icon from a save box in order to specify where to save a file.

In RISC OS the Filer provides many simple means of working with directories and files, including simple means of performing most basic file operations. To see the details in an Application Directory hold down shift while opening the Application, to select specific items use adjust click to make the selection (in RISC OS the right mouse button is called Adjust), Adjust double click to open a directory while closing the parent, etc.

How do you keep everything about an application together, to the point of making installation usually nothing more than drag and drop? Well you have all the applications resources, settings, etc held together in some way. In RISC OS this is done by having all the resources for an application inside a special kind of directory that looks like a program file normally, and will run the program if double clicked, though is actually a directory and can be opened as a directory by holding down shift. To specify a directory as being an Application, the directory name begins with an explanation point (called a pling in RISC OS) character '!'. Applications usually have a custom Icon for there application directory, this is contained in a Sprite File (raster graphics file in RISC OS) inside the Application Directory.

Inside a standard Application Directory are a few scripts, an optional help file, the program file itself, any resources used by the application, and a Sprite File for the application Directory. Within the application directory an Obey File (script) named !Run is ran when the application directory is double clicked on, a file named !Help is opened if the Help option is selected for that application from the filer menu, a file named !Sprites (or !Sprites22, or some others) contains the sprites for the Program Icon usually. There is also usually a !Boot file that is automatically ran when the filer display containing the application is first opened, this sets any environment variables that should persist even when the program is not running (like file type associations to open with this program, etc).

You may recognize the concept, as a number of modern Operating Systems are now starting to do the same basic thing ("Mac OS X" and its application bundles, some newer concepts in Unix like OS's, etc). This has been part of RISC OS since at least 1989, and continues to be part of our OS.

Using standard output for text includes not just standard terminal type commands, though also graphics output. This is VDU output, that is able to produce good graphics using the text output, as well as set cursor position, clear the screen, set the clipping area, and more.

From the line of BASIC interpreters known as BBC BASIC, ARM BASIC also known as BASIC V or BBC BASIC V is an extremely good BASIC interpreter supporting full structured programming. There is never a need for goto or gosub (really there is never a need) in BASIC V.

Including simple means of making OS SWI Calls (using the SYS statement), it is easy to write any kind of program in BASIC, including full multitasking windowing graphical programs.

With very good support for indirection, and simple to use indirection at that, there is no limit to how you do something in BASIC V. A compiled version, could hypothetically be used to produce an entire Operating System (though the current Compilers do not allow for this).

This author would recommend anyone using RISC OS, even if new to RISC OS, take the time to learn this version of BASIC. It is built into every single copy of RISC OS being part of the ROM. Though do not type programs directly into the interpreter, use !Edit or !Zap or similar (we are not in the early 1980s anymore).

Then there is an extremely good ARM Assembler built into BASIC V, that makes producing fast binaries and modules very easy. ARM Assembly Language is well worth learning, and as assembly languages go it is one of the easiest to work with.

Yes RISC OS uses Cooperative Multitasking, though it is different than you would expect. Every program is protected from other programs, and every program is swapped into the memory space with a base address of 0x8000, so applications know there base address.

As with most OS's that use cooperative multitasking, RISC OS strongly encourages good programming habits. This because if your program, that is supposed to multitask (there are single tasking programs), hogs too much time causing the system to stall out noticeably, then it is unlikely to be used. This is one of the huge advantages of cooperative multitasking over preemptive multitasking.

Like with many cooperative multitasking systems, task switching takes place when an application polls for events. In RISC OS this is done either by calling Wimp_Poll or Wimp_PollIdle, which are also used to receive messages in addition to normal Windowing events.

It is also possible to have module tasks, in which case the base address of the executable is not changed, though they usually still have memory allocated in the region beginning at 0x8000.

From the point of view of low level usage, RISC OS has one of the easiest to use, most versatile Sound Systems of any OS I am familiar with. It is easy to setup a sound buffer of a specific sample rate, and with support for multi-channel sound at very high sample rates the versatility and simplicity combined is unmatched.

Actually there are two sound systems (backwards compatibility), the old Archimedes 8-bit per sample logarithmic system, and the SharedSound system. Though the current SharedSound 16-bit per sample stereo sound system is the most logical to use, mostly as it matches the current HW the best.

Once you are initialized as a handler, have your buffer, and are setup to handle the interrupt for sound, you just fill the buffer passed in on the fill interrupt with samples having the two stereo channels one in the low 16-bits of each word and one in the high 16 bits, it does not get much easier than that. And if you are a multitasking application you can either create an executable dynamic area, or write a module, to handle the buffer fill interrupt (more of a callback from an interrupt, though basic concept).

Even if working with an old RISC OS that uses the 8-bit system the concept is not much different for direct sound output. Though as the sound HW is known to be the VIDC the sound buffers are directly handled by the HW. That and you have to remember that the amplitude being passed to the sound buffer values is log2, thus not linear though a lot richer than almost any other 8-bit sound system.

The native raster graphics (pixel map) image in RISC OS is known as a "Sprite". While they can be used like Sprites in other systems, they are just Raster graphics images of the format native to RISC OS. RISC OS provides a wide range of operations to work with Sprites.

You can transform a sprite against an arbitrary fixed point transform matrix, rotate a sprite, insert rows, insert columns, delete rows, delete columns, transform across to a different bit-depth, etc. Sprites are stored in memory in what are called Sprite Areas. Sprite Areas can contain any number of sprites.

Two special sprite areas exist, one for the OS Sprite area, and one for the WIMP. The WIMP Sprite area contains all the icon sprites for programs, document types, folders, etc. Also in the WIMP Sprite Area are the sprites for window decorations, window background image, button faces, and other controls that can be changed by the current theme in use.

RISC OS can easily be modified by taking advantage of the standard vectors, as well as by paying attention to service broadcasts. Vectors provide a way to override or supplement many of the standard OS functions, from Sprite Ops to the VDU stream, and just about everything in between. Also some vectors are just an application to themselves, like the fast timer vector.

Put simply a vector is used to specify what code is called when the OS tries to perform certain operations, and can be handled by a user module (or in some cases even a user program). This is a way to patch and modify the behavior of certain aspects of the OS, as well as provide extended functionality.

In RISC OS Modules provide just about all the OS functionality, and you can add more modules. User modules can provide new functionality, extend existing functionality, replace system functionality, or just be an application. Modules run mostly in Service mode, which is privileged and means that they do not benefit from the normal task memory protection, thus extra care should be taken to be correct in writing a module so you do not crash the system. That said when learning it is interesting to learn what crashes the system and how, as well as to remember that just because you crash the system do to a small mistake or misunderstanding it is still a good thing as we learn from it, and it just means waiting for a reboot.

Modules are often used to provide SWI services for applications to use. The SWI is the standard way of making system calls in RISC OS, and is an easy thing to handle in Modules. It is also possible to override existing SWI handlers to either replace there functionality or to supplement or extend them. The module format is designed to make it easy to provide SWI services.

Many modules also provide star commands (commands for the standard CLI) that are related to what else they do. The standard module format provides an easy to implement Star Commands (as well as a help string for the module).

Some modules need to monitor services. These include modules that implement File Systems (including Image File Systems). There is a simple way to specify that you want your module to receive services.

Then there is the exception to the normal use of modules, module Application Tasks. It is possible for a module to just be an application (as well as to be both a program and provide other services), and there is a standard way to specify this including the entry point for execution to start. If you register as a Wimp Task in your module application you will be given a Wimp Slot of memory when active starting at 0x8000, which is the area you should use for most of your tasks data (you can also use dynamic areas or RMA memory for that of course).

RISC OS is the first widely used OS on ARM CPU's, and is very much designed with the ARM in mind in many ways. It is the only OS that can be said to be an ARM OS that I know of. Everything from the SWI system of calls, to the way many things are handled.

RISC OS does not pose any restrictions on application software running on it. This to the point it is possible for an application to completely take over from RISC OS and become a replacement OS.

For programs running within RISC OS this means that the Services of the OS are available, and the OS will not prevent the application from doing what it may need to to reach the best performance.

• The ARM CPU : It is easy to emulate other CPU's on an ARM.
• File Systems and Image File Systems : The way RISC OS handles just about any file system, and the natural way it handles disk images (image file systems).
• Raster Graphics : The way RISC OS handles Raster Graphics simplifies life for graphical output from an emulated computer.
• OS stays out of the way : RISC OS staying out of the way where needed increases the ability for an emulator to do very well.
• Cooperative Multitasking : The ability to control directly how often the emulator tasks out makes it easy to tune performance in an emulator.
• Support for Single Tasking : The ability for the emulator to single task allows an emulator to be the only active task and run very fast if well written.
• Assembly Language is Simple : Usually it ends up best to write most of an emulator in Assembly Languge. The ARM 32-bit assembly language is a very nice assembly language, and RISC OS comes with a fairly good assembler (built into BASIC V).
• Ease of Endians : On old ARMv2 and ARMv2 CPU's it was easy to do software byteswapping, on newer ARMv4, ARMv5, ARNv6, and ARMv7 CPU's it is possible for an application to run with big endian data format while everything else stays little endian.