Running RISC OS Programs on Linux - RISC OS News, Software and Information

Running RISC OS Programs on Linux

Published: 31st Mar 2005, 19:31:03GMT Source: drobe.co.uk
By Peter Naulls

Page 1 of 1

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]

simo (+1.6) 31/3/05 7:54PM	Interesting idea Peter. But is it the RISC OS applications that keep people on the platform, or the OS itself? Most of the big RISC OS apps have been ported to Windows in some form (Messenger, Ovation, ArtWorks, Sibelius, PipeDream....) but we still have a following using them on RISC OS - probably more than use them under Windows. So I'd argue that the OS itself (stabilty, WIMP etc.) is the bit that keeps people on the platform, paying OTT prices for hardware etc; not the applications. The same could be said for Linux - most of the popular Linux apps work under Windows too, but people still use Linux. Also, you can get much better editors than StrongED under Linux/Windows!
markee174 31/3/05 8:03PM	*In reply to Simo:* Much better editors such as.... MArkee
md0u80c9 31/3/05 8:54PM	Well, you can get better editors on RISC OS too. Zap springs immediately to mind ;oD.
leeshep (+2.5) 31/3/05 9:02PM	oh, here we go again the zap vs StrongED rift , back on topic I think RISC OS apps will always run better (maybe not faster) on proper RISC OS hardware (something to do with the decent GUI
rowledge (+1.5) 31/3/05 9:35PM	MOre interesting to me would be running RISC OS on top of a linux/unix kernel on ARM hardware. At least that would avoid the effort of emulating the cpu; I fully understand that that is not a major fraction of the work. It would, just maybe, provide a more reliable kernel upon which to run my favourite RISC OS apps. It would just possibly help with making PMT available along with serious memory protecction. I understand that some areas of RISC OS are claimed to be not easy to make work in a PMT OS but we've seen that pretty much all apps can be converted from 26 to 32 bit model, something that was pooh-poohed not so long ago. If some changes to cope with PMT were needed I suspect a similar effort would be made by many authors. While we're at it, how about adopting a more modern FS? Might as well get past all the pain in one go. Yes, yes, I'm dreaming. So sue me.
jess 31/3/05 9:37PM	Would this arrangement work under cygwin with windows? If a system like this were to appear (especially if cygwin were possible), I would think its biggest use would be to allow RISC OS users to use the same programs on other systems, rather than to help them to migrate away. It might also improve the user base for some programs outside current RISC OS users.
jcmcculloch 31/3/05 10:47PM	Could this be an Early 1st of April ditty
moss 31/3/05 10:51PM	No.
mrchocky 31/3/05 11:17PM	*In reply to moss:* can you be sure *In reply to jess:* What I've proposed doesn't rely on anything specfically Linux (except maybe some bits in QEMU), it's just using various libraries, so it could work just the same. Although the idea of using RISC OS apps under Windows is somehow less than appealing. *In reply to rowledge:* The problem is, that the whole idea of "RISC OS on top of a unix kernel" all falls to bits if you examine it too closely. No one's been able to put together any kind of sensible plan that you couldn't drive a truck through - even to the level that I've done in the above, which has plenty of (small) holes in it. The first problem is to define where the RISC OS bits finish and where the unix bits begin, and how they all fit together. It sounds great, but I don't really think it can be made to work; the systems are just too different at that level.
johnpettigrew 1/4/05 10:36AM	Interesting idea, but with a few problems. As has been said, several of the crucial RISC OS apps have been ported to Windows, and hence run on linux under wine - OvationPro, which you use as an example, is one such. However, it would be interesting to see which worked better - emulating a windows version or a RISC OS version
jess 1/4/05 4:25PM	mrchocky; Using Windows apps under Windows is even less appealing
rowledge (+1.0) 1/4/05 5:16PM	In reply to Mr Chocky: if you have any pointers to stuff written on the subject I'd be interested to read them. Aside from the trite "it's only software so all it takes is work" aspect there is the example of Apple moving from ancient CMT on 68k to a full unixoid on PPC (and doing so extremely well) as motivatin. Sure, we lack a few hundred million dollars but what the hell. I don't imagine you'd disagree that the UI could be supported. I have tried ROX a few times and although it has diverged rather a lott it showed the principle quite well. There is also the example of VMWorks (I think - the app that lets you run unix under windows, windows under unix and so on) as an extreme way to tackle it. THey also avoid the different cpu problem. Perhaps rather than saying 'run RISC OS on top of a unix kernel' it might be more useful to say "could an OS be built on top of the kernel of linux/bsd/whatever that would be sufficiently like RISC OS to please users and attractive enough to developer to get them to reowrk their software". Sadly I lack the large amount of spare cash to offer to support such an effort. Wish it were otherwise.
caliston2 2/4/05 7:49PM	*In reply to rowledge:* We did this in some detail on csa.advocacy a few weeks ago: http://tinyurl.com/6wnvj
tapina 2/4/05 10:36PM	I started working on this but for the Java platform so it worked anywhere. I was taking the approach outlined - picking an app and getting it to work by seeing which SWIs it used. It also seemed sensible to choose an app for which source was available and which was pure assembler to avoid having to implement SharedCLib or Basic interpretation straight off so I'm using StrongARM. I've got the core ARM emulation mostly working (some mishandling of the call stack still) and a framework for plugging in SWI implementations in Java. The idea is that the program gets built in blocks and pure Java versions of performance critical sections could be substituted for certain blocks or a Java compiled bytecode version could be substituted for the semi-interpreted version for blocks. Being Java, the question of which GUI library or platform quickly becomes irrelevant and the APIs are not a bad match either in most cases. Anyone interested in getting involved, please get in touch.
rowledge 3/4/05 7:30PM	reply to caliston2: thanks for the pointer. I don't read .advocacy so I missed this. What a depressing thread; so much rudeness, arrogance, nastiness. Barely a useful paragraph in the lot. I withdraw my last comment above - I _don't_ wish I could support the idea. It would clearly be a waste of time to even consider.
Bungee 7/4/05 10:02PM	I find this especially interesting. I would like to make the point that ROX with the OroboROX window manager (currently v 0.9.6.11) can be configured to be very RISC OS like in behaviour. Whether this would actually help or hinder the project I do't know!
drjones69 6/6/05 11:17AM	Not sure if anyone is still reading replies to this thread, but here's my oar put in... I'd dearly love to be running my RISC OS apps on this Linux laptop. Can't vouch for everyone, but I certainly stick with RISC OS for the applications. Of the examples given, Ovation Pro does run under WINE, but using it is another matter, I get all manner of random crashes (less so with latest cvs version, but still there) and not worked out how to get it to print yet. But StrongEd kicks ass compared to the current editor I use (kate) and I really really want StrongEd!! TechWriter blows KWord out of the water (and fwiw, I much prefer it to OpenOffice.org also). Artworks leaves InkScape standing and don't even get me started on the bloody mess that OvationPro leaves in a celebrity deathmatch with Scribus. Please please consider porting at least some of these to Linux, for most I'd be more than willing to cough up for a 2nd license (and I'm a stingy git!). I suppose VA for Linux would alleviate some of my probs (hint hint, please please, beg beg!). On a more serious note, surely there is substantial revenue opportunities for many RISC OS under linux - not that I've been using it that long, but there does seem to be many fewer 'dominant' apps and perhaps RISC OS ports would stand a damn good chance with fewer 'big-boys' around. Regards, Ryan PS. God do I dislike laptop keyboards!!! 16 time I clipped the touch pad and sent the window scrolling - just thought I'd mention it (make it 17 times now!) GRRR!