Drobe Launchpad | Running RISC OS Programs on Linux

Running RISC OS Programs on Linux

Published on 31st Mar 2005, 19:31:03, source is drobe.co.uk
By Peter Naulls

Peter Naulls contemplates the possibilities

After the disbanding of Acorn, there was not an inconsiderable debate about how to save RISC OS. Whilst the most obvious and practical result of that was RISCOS Ltd, an idea aired many times was the dream of getting RISC OS apps to run natively under Linux or other Unix-based operating systems. A variety of wild ideas were named, with credibility from ill-considered to just about plausible given a vast amount of work.

One idea that did make a little bit of headway was Riscose, by Matthew Bloch. The idea consisted of an ARM emulator running under Linux with emulation of some SWIs. Whilst he did have a little success running some basic command line programs, it was largely only meant as a toy and probably unlikely to become anything significant. Riscose was all but forgotten when Matthew moved away from RISC OS.

The idea
What I'm proposing isn't so different from Riscose. The main contrasting features are use as much as possible of existing solutions, plus something that's already in use. If you paid closed attention to our recent article on GCC 4, you may have noticed that Nick Burrett is already running RISC OS programs under Linux. At least, he's running command line programs which make relatively few demands of RISC OS SWIs.

What Nick's done is to take an older system he developed which used the original ARM emulator and implemented enough SWIs in it to allow Unixlib programs to work correctly. He's replaced the emulator and instead used QEMU, which is considerably faster. In fact, it performs at around RiscPC speed on a 1.8GHz machine (similar to VirtualRiscPC).

So what's the problem
It looks like we already have everything to run RISC OS programs directly under Linux, so what's the big deal? It turns out that there are a large number of problems, and making a comprehensive solution that could run arbitrary programs would be very difficult indeed.

The most obvious problem is the enormous number of SWIs provided by RISC OS that would have to be emulated; and emulated precisely so that things will work properly: SWIs being the software interfaces that programs use to tell RISC OS and modules to perform tasks for them, such as opening files and creating icons on the screen. Also, modules provide a big problem - being able to execute them would be very difficult in most cases. There are a host of smaller problems too - how to run BASIC programs (Brandy might go some way towards this), handling of Obey scripts, system variables and other RISC OS paraphernalia.

This would make prorgrams that used the toolbox, for example, a bad choice. Or any use of a module for which you could not emulate its functionality by emulating its SWIs.

What could work
Most RISC OS programs only use a limited number of SWI calls; and of the functionality provided by those calls, most use only a small part. The interesting RISC OS programs of course mostly use the Wimp and not the command line, so this is one area where most or all of the functionality must be complete. This is a doable task, for reasons we'll come to in a moment.

What would be a practical task in terms of time and effort is to pick a small number of RISC OS apps that you'd like to run. For purposes of this article, I'll name Ovation Pro - it's a popular RISC OS application and only has a small number of module requirements, and is presumably well behaved. Of course, I've not investigated this fully, and it might prove not to be such a good choice for technical reasons, but this doesn't matter too much for the purposes of illustration.

In short, the system would run the Ovation Pro binary under an ARM emulator. Any SWIs it encountered would be passed to a RISC OS emulation layer, including filename translation. SharedCLibrary calls can be passed directly to the Linux C Library, since both fully implement the ANSI C specification. Other SWIs that were used would be implemented as required.

Wimp Behaviour
To implement Wimp behaviour under Linux, the SWIs that concern us most are those provided by the Wimp itself, the font manager and the sprite sub system. To provide these, my suggestion would be to translate the calls to GTK. Why GTK? Mostly because of my familiarity with it, but also because it's quite easy to use, is widely available, configurable and flexible enough to do what's required. Plus emulated RISC OS apps using it will have a degree of consistency with other Linux applications that use it (as many major applications do). Another good choice would be Qt, as used by KDE apps, and similar arguments can be made.

Figure 1: OvationPro

Figure 2: StrongED

In figure 1, we've mocked up what Ovation Pro might look under just such a system. Figure 2 shows StrongED; Zap and StrongED have been prime candidates for requests to convert to Linux since there really is nothing like them anywhere else. Click on a thumbnail to view the full spoof.

A case might even be made for integration into ROX, although ironically, even though it bases itself upon RISC OS, it does differ in some details, and further study would be needed to see if this is practical.

In this case of the mock ups they're using a standard Linux window manager for the window tools. If you wanted to go the whole hog, it's not too difficult to make a RISC OS look and feel for your favourite window manager. Indeed, KDE includes a "widget" look and feel which is precisely this.

One interesting problem I will note is that it's not possible in advance (unless you're using the toolbox) to determine if a window will have a menu or not. This, and other reasons, mean that RISC OS apps under Linux would not have drop down menus, but would have to retain their context-sensitive menus.

Wrapping Up
So, that's it. It's possible, in a limited fashion, to directly a small and specific number of popular RISC OS apps under Linux. But will it happen? Well, I won't be doing it, but someone else might.

Links
Riscose
QEMU
GTK
KDE
ROX

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

Design and concept (c) Fudgecake Design, 1999 - 2001. Content (c) The Drobe Team, 1999 - 2006. See www.drobe.co.uk for more information. For non-commercial personal use only.