RISC OS

As has become something of a tradition, at the end of each year, I speculate on what's in store for the next year. The problem is, looking back at my predictions for 2005, they really weren't very inspired, and I didn't go out on much of a limb to make them in the same way I did for the previous year. I won't bother you with the details of what I did say, but suffice to say there wasn't too much worth repeating.

For 2006, I'll change the plan a little. I'll instead suggest some projects that are both plausible and possible in a relatively short space of time. As you might imagine, many of these relate to previous work I've done. Whether they will be carried out is another matter entirely, and nothing should be read into these that I or anyone else intends to carry them out. One prediction I will make right now is that I expect developer support to continue to wane in 2006, with an increasingly frustrating general RISC OS situation, which for the first time in a long time, has only a little to do with technical restrictions.

2006 Possibilities

Java. No again, you ask? Yes, again. Ports of GCJ (i.e, part of the GCC project) and Kaffe remain very much possible. A version of the latter was demonstrated some considerable time ago, but it needs some commitment to be brought up to date, and its AWT can be arranged to use ChoX11 and my other recent work. A relative novice RISC OS programmer could probably do this with a little help.

RealPlayer. Well, maybe. Much of the technology for this exists in an open source form, but will certainly require some additonal work. It's not clear (to me) how complete a solution this would be without additional closed source codecs, since this continues to change.

Shared Libraries. I've covered this topic extensively in the past. Lee Noar's already done most of the imporant ground work, but there's a lot of nuts and bolts integration to be done.

Packaging. Despite extensive politiking of this subject in 2004/2005, and the great work of Graham Shaw, little has happened. Whether this is due to ignorance, lack of interest, or being stuck in the mud isn't entirely clear. Either way, questions like "where can I find program X" or "what's the latest version of this program?" or "how can I ensure my system is up to date?", continued to be one of the most comment themes on RISC OS support forums. All this, and many more problems can be solved by packaging. Moreover, much of the work can be done by non-developers. RISC OS needs this badly, but I fear the will is not there. Still, the door remains open for it to be done.

Bug fixes in RISC OS 5. Honestly, Castle. You had a great first year after the Iyonix with updates to RISC OS, but there are still a handful of stupid bugs and misfeatures that could be easily (and I really do mean easily) fixed in RISC OS 5 and haven't been after 3 years. Things like filename behaviour in CDFS, the bad state of LanManFS, the dire, and completely non-style guide compliant IyonixWatcher interface. Don't forget the sample rate handling default (22kHz - doh!), lack of memory protection on memory below application space, which would see a considerable improvement in OS stability. Let's not forget the ShareFS debacle (ok, that's not entirely fair, but Castle are in a position to do something about it). Also the insane design of ADFS and friends as well as the ridiculous state of RISC OS formatters (both these are Acorn's fault, but it would benefit Castle greatly to address them).

Opening up RISC OS. Yes, I know there are legal restrictions on what Castle and ROL can do with RISC OS sources.  I talked previously about Open Sourcing RISC OS. However, anything that can be done to open up RISC OS internals, create new APIs or do something complete novel (and of course, legal) will give RISC OS some street cred, and might do a little to revitalise development.

RISCOS Limited Helping out Developers. Hmm. Tricky one. ROL recently found itself completely at odds with developers over assertions about Select, not to mention to that Paul Middleton thought that name-calling was a good way to promote his company's Adjust developments to programmers in a position to take advantage of them.  Yes, I know ROL's resources are very limited. Still, if Adjust is to be taken seriously on machines other than RiscPCs, then ROL must take developers seriously. 

VirtualRiscPC for Linux. Back on solid ground with this one.  It even exists, and for me, it would remove the singular reason I still need to use Windows, along with its endless maintenance.  I've had one virus this year (for the first time ever), and if I continue to use Windows, I expect to get more. I know that Linux isn't for everyone and won't be for a long time, but for my uses it offers so much more flexibility and openess than Windows and is a far better basis for doing my RISC OS development than sticking with Cygwin as I've been doing for some months.  I know that VirtualAcorn isn't a Linux support house, and they have genuine concerns in this area, but I have no doubt that there are more than enough RISC OS enthusiasts who are also Linux experts to fill this gap, as well as a ready market for people who feel similarly to me.

JavaScript support in NetSurf. It could happen - it's a lot of effort, but who knows. It depends on the developers deciding that this is a prority for them, above other thing that may deserve more attention to bring to completion.  I would say not to expect any miracles here - it would likely take all of 2006 and beyond.

Open Sourcing ViewFinder Software. Ok, the practical benefits here are a bit limited since it's hardware for a distincly old machine, but John Kortink might gain some karma points, and there might be some interest in improving it. 

Lack of Windows Bashing. No, what I've said above about Windows is just my frustration with it. I'm talking about the out and out bashing of Windows and its perceived deficiencies from RISC OS users for no purpose other than to rant.  Please, this does not put RISC OS users in a good light - put your energies to better use to solve the problems RISC OS has.  Yes, Paul Vigay, I'm talking about you, although you aren't the only culprit.

OpenOffice.org. Ok, I'm kidding.  OpenOffice.org is a monolithic program (800MBs of source), it doesn't cross compile (which precludes most of my traditional porting methods) and relies on things RISC OS doesn't yet have like shared libraries mentioned above.  I should know - remember, I did the ARM Linux port.  And even on an Iyonix its speed wasn't anything to write home about.  True, OO.org would be a fantastic headliner for RISC OS to boast having in the same way Firefox was, but from a practical standpoint - its ability to read MS Office formats - there are more practical alternatives.  Take a look at ABIWord, Gnumeric or even KOffice, and some of the other office programs floating about.  At least some of these could be made to work on RISC OS.

"Ready to Go" RISC OS demo.  I'm not going to say too much about this, since I plan to expand on this in a future article, but the idea is simple - at least it appears to be simple, which is the important point.  In short, something Windows, Linux or Mac OS X users could download and fire up with little effort and see what RISC OS is like. It wouldn't have to be super-fast and RISC OS 3.1 would certainly do. To give you an idea of what I'm on about, take a look at Damn Small Linux.

That's your lot

For this year, anyway.  I'd just ask if you care to add your predictions, try to base them in some kind of reality.  Blue sky predictions are one thing, practical suggestions another.