It's a lot - just for the one specific window I wanted to open, and ignoring all events being passed into it.

If you wanted to dig up your stuff if you still have it, then we can take a look.

I'm also not a GTK programmer, so the code was ... functional at best :)

The idea behind it was to have SWIs emulated using .so/.dll in chunks of 64 (so if you had written your own module in C, you could simply recompile it [assuming you didn't call other SWIs that hadn't been treated] with a different veneer to CMHG/cmunge), so all you needed was a "swi400c0.so" present in the library path to do the WIMP SWIs (for example). The modifications were to the SWI instruction, so it looked for the SWI chunk handler and called that.

Although you'd probably already thought of doing it that way :)

From memory, you could only set the window's size and title. And maybe the background colour. I really didn't get that far with it!

What is it with some people? Are they of such feeble constitution that they can't bear to speak of having an architecture at home that is different to that of their peers? Be proud or if not that - *pleased* - there is an alternative platform which at least provides a foundation for independent innovation rather than catch-up and total ultimate convergence.

Given that there's a lobby that is constantly pressing for this, I'd say having Peter's blog is pretty crucial.

1) RISC OS very badly needs to be modernised with a new back-end. This will require a lot of hard work and almost certainly break a load of software anyway, so it would be the best possible time to change architecture.

2) VRPC performance on a powerful x86 box is comparable to an ARM-based machine, and given that with a new architecture, only some applications (and not the whole OS) would be emulated, there should be some performance improvement. x86 is going multi-core while ARM almost certainly isn't, so the performance gap could very well increase over the next few years.

3) Drivers may not be such a problem if a new RISC OS back-end was to be based on an existing open source kernel (like Mac OS 9 -> Mac OS X), and at the very least it would be possible to look at (for example) Linux drivers in order to get x86 drivers for RISC OS. It's also worth noting that the selection of hardware for RISC OS is currently quite limited, so there would probably be an improvement even with a limited number of drivers.

As soon as the hardware is comparable to PCs, there'd be no point developing original software and any developers would be absorbed into the PC world or more accurately cease to use any of their spare time developing for RISC OS.

There would still be point in developing original software, because quite simply nobody likes having to dual-boot and use an operating system they don't like (such as Windows) just to perform a particular task. Just look at the amount of work that has gone into Linux to achieve the same functionality as Windows.

Finally, unless a new version of RISC OS included built-in GTK/X Windows support, the work on Firefox wouldn't go to waste.

Of course, debunking that idea is very easy indeed, since it doesn't make any sense. :-)

It makes much more sense to make use of the hundreds, if not thousands, of person-years of effort that has gone into a freely available OS to provide the guts of the operating system and add as many unique selling points of RISC OS (i.e. the GUI, maybe the font manager) as possible to it.

However, this idea (I'm assuming that was what was meant by the header "But it could run on an interface layer and talk to Linux drivers, etc") isn't described in any detail in the blog, nor are any references to such suggestions (and subsequent discussions) made. Describing previous discussion of an idea as "unfortunate hand-waving" to suggest that the idea is without merit doesn't actually seem to me to be a discussion of the problems, at all, much less debunk the idea.

In short, I think the article is short of references and detail and doesn't move any discussion forward, nor reduce any controversy. YMMV.

Andrew: I used to be proud of my Acorn A440/1 and later RiscPC (especially when I added the SA processor, which I'm still using in preference to anything else for day to day stuff). I was proud, not just because they were different, but also because they were equal to or better than the alternatives; there is now no chance of the native hardware catching up with the ever-moving mainstream hardware, and it looks as if Intel are working on removing the low power advantage of ARM processors, as well. If Apple and IBM can't keep up, what chance anyone else?

Simon

The answer to that seems to be to dismiss applications as being unimportant, or to say that them going slow is fine, which seems to be a way of burying your head in the sand.

If it was easy to port RISC OS there I'm pretty certain it would've been done a long time ago.

From the comments here, and what you've said elsewhere, I have inferred that the badness of the idea is that it would be a lot of work for not much speed benefit. Is this correct?

My, layman, understanding of it is that it is even more problematic than that: lots/all/most (dunno which!) software would stop working. Given the current state of the RISC OS market I don't think it could withstand such a decimation of the existing software base. It would be like trying to start a new OS from scratch.

Adam

Imagine RISC OS had never existed, and you'd come up with this idea for an OS which was much nicer to use than anything else (putting aside the issues where it's out of date) - you might not chose x86 to create it on, but if you wanted it to run on anything other than small handheld devices I'm pretty sure you wouldn't use ARM.

Some people anyway.

> The strengths of ARM aren't relevent to the machines we're talking about

There are a class of machines where it's relevent.

> and most of us from time to time have to use other computers. Sometimes that's for software reasons, which is a different issue, and sometimes for hardware - encoding MP3s to put onto my portable player is far too painful on RO

Indeed.

> Imagine RISC OS had never existed, and you'd come up with this idea for an OS which was much nicer to use than anything else (putting aside the issues where it's out of date) - you might not chose x86 to create it on, but if you wanted it to run on anything other than small handheld devices I'm pretty sure you wouldn't use ARM.

You'd make it portable.

Which is why the future of RISC OS is twofold. One: Continue RISC OS on ARM for more portable devices. Two: Recreate the RISC OS experiance on an open source portable OS

Recreate the RISC OS experiance on an open source portable OS

I do hope you've thought hard about this issue, and are not simply waving your hands!

The blog seems to be available again, by the way (and this time I've kept a copy).

Simon

> I do hope you've thought hard about this issue, and are not simply waving your hands!

Well, I've thought a bit, you'd need a GUI, toolkit, there's already a BASIC port, command line commands would need to be reimplemented and you'd need a compatible shell. You should call it ROGUE: Risc OS Gui Unix Environment. An advantage is any one of these things would be good, you don't need a finished complete project to use it.

Once you got to that point you could write ROUGE apps, and any RISC OS stuff that was just BASIC or Obey files would run.

It would probably be a good idea to hook an emulator in so native ARM apps would run.

The implementation is left as an exercise to the reader, or you can wait until I know more about unix.

> The blog seems to be available again, by the way (and this time I've kept a copy).

New month, new bandwidth. Next time don't post to OSnews.com :-)

I think Peter's misconception is that people want RO applications running on non-ARM hardware; personally, there are few, if any, RO applications I couldn't do without, but I love the GUI.

All the RO applications I use run very nicely on a StrongARM RPC, and I don't need them to run faster (although I wouldn't complain). New programs, however, I'd like to run like the clappers!

I'd like to do digital video editing with the RO GUI, rip CDs (for personal use), etc. Other people might like to use Firefox and OpenOffice; these already work on Linux (obviously) and if it's too difficult to get them to look ROLF-native, they can still run as X programs.

I'd also like to use the latest (or at least only a few years old) hardware add-ons to do, say, DVB recording from satellite and terrestrial broadcasts, write DVDs, get movies from my camcorder over firewire, and probably other things.

Also, using Linux as a foundation means that the code can run on ARMs, PowerPCs and goodness knows what else as well as x86.

I don't know if anyone else would like that, but that's not really the point, is it?

The user experience when using compatible RO Apps and ROX apps would be like RISC OS, but there would always be the option of using plain linux apps (or even WiNE) if the need arose.

I don't think this would be a replacement for RISC OS, merely an alternative which would likely be of interest to those who have moved to Linux and as a second system for those for whom RISC OS does not provide a comlete answer.

If there were co-ordination between the set of SWIs provided by this and the java RISC OS emulator, it would (eventually) give application writers a much bigger potential audience.