RISC OS

If you're looking for an article that was previously here, then you probably ought to be looking at http://www.riscos.info/

 

If you've followed my writings, you'll know I've been hoping for an open source RiscPC emulation solution, or perhaps a Linux version of VirtualRPC.  Well, the latter hasn't happened sadly, but the former has.  Or at least, it's in the process of happening.

When Tom Walker released the sources to RPCEmu, his RiscPC emulator for Windows in January, I was quickly able to turn around a port for Linux and much a bunch of other improvements - such is the nature of open source software.  Now, this Linux port is very immature, so don't go asking me for a release  All I will say is that it works, but needs lots of things done to it.  Some of its support like HostFS is taken from ArcEm work, and ArcEm has also recently gain from some other stuff Tom did. And since I won't have any time in the immediate future to do a load of work on it, I've asked the rest of the ArcEm team how they'd like to contribute.

So, that's basically it.  There's a Linux/Windows/Other OS RiscPC emulator in the works, but it's likely to be some months before it reaches any kind of polished state.  You can try out Tom's release of the Windows version in the meantime.  If you'd like to contribute, then its source is held under Subversion on riscos.info - get in touch if this interests you.

And of course top marks to Tom for doing this in the first place, and agreeing to place it under the GPL after a number of suggestions I made to him about possibilities for clarifying source ownership.

 

Selling RISC OS to the general public is always going to be difficult; despite some software developements in the last few years, it still lacks features which have long since been ubiquitous on other platforms - especially what might be termed the big three - Windows (more relevantly, WinXP), Mac OS X and Linux.

What naturally compounds this is the near commodity status of PC hardware. For example, recent sale prices have seen entry level laptops in the United States drop as low as 250 GPB., and desktops even lower. I'm sure that similar pricing will soon follow in the UK. This is clearly an impossible situation for RISC OS hardware to match, and it must continue to trade on its other merits of usability.

The mass-market PC still implies, for the most part, WinXP, with of course the significant niche carved out by Apple, not least helped recently by its attention to style and products like the Mac Mini. But what's interesting is that despite all the noise about Linux, and very real and significant usage in server solutions for Linux (even apart from the traditional Apache et al presense on the internet), 2005 failed to be the prophesied "year of the Linux desktop" - at least, in any meaningful way in the mainstream - and it's still very hard to purchase a PC with Linux preinstalled.

As for RISC OS, it clearly has many problems to overcome before it can really gain any wider appeal. But instead of mentioning those in further detail once again, I'd like to cover a topic I hinted at in a earlier article - a ready to go RISC OS demo.

RISC OS Demo

So how would such a thing work? The major problem with providing something that people are able to download and immediately run on their commodity hardware without messing around with extra downloads, or having to pay anything, is licensing. RedSquirrel went some way towards this, but you still had to locate RISC OS, and put together a boot sequence, etc. Similar comments can be made of the other emulators like ArcEm and Arculator.

To demonstrate the strongest point of RISC OS - its GUI, and the way applications interact with that and other applications instead of the semi-typical monolithic approach - doesn't require the latest and greatest. In fact, RISC OS 3.1 will do fine as long as the emulator has a reasonable amount of memory, and a polished boot sequence, and can take advantage of things like long filenames via a host filing system. It would of course need to be furnished with some applications, and some kind of tutorial to really get people involved. Oh, and did I mention it needs to be really easy to get going?

I previously mentioned Damn Small Linux. This is an appealing model, as it is a single, relatively small download (well, 50MB) and within a few seconds you can unzip it, and be running a windowed fully-featured Linux desktop within Windows.

RISC OS Licensing

As I mentioned, and has been debated much in the past, the problem remains with the legal status of RISC OS ROM images - the rest is entirely possible under freely available RISC OS software and RISC OS hardware emulation software.  In particular, with RISC OS 3.1 ROM images, of which the status of I won't begin to speculate about.  What I can agree with is that their value to RISC OS may be greater if freedom is given to pass them around with impunity.  This would allow completion of such an emulated environment, and put an end to the underhand (not to mention illegal) passing around of RISC OS 3.1 ROM images.  It would also gain some karma points and publicity for any companies involved in making this happen.

As for images of later vesions of RISC OS - particularly RISC OS 3.7, 4 and Select - their legal status is arguably much clearer, and I don't advocate making images available except under existing or new commerical arrangments, especially while they may still have value to the companies involved.

The Components
So, a recap of what would be needed to put this together.

An emulator - ArcEm is perhaps the obvious choice.  It runs on Windows, Linux and Mac OS X already, has active developers and development versions boast a hostfs host filing system.  Its source is available for anyone to hack on, or port to a new system.  It still requires some polish before a release could be done, but this is a matter of time.

Boot sequence and applications - this requires someone to take some time to put together a modern boot sequence, perhaps with various patches to provide features not found in a vanilla RISC OS 3.1 setup.  It also requires a selection of apps - these need to be well-chosen to demonstrate the strong points of RISC OS, and should not be an ad-hoc collection of the "usual suspects".  The files would live on the host filing system, rather than under the restrictions of a RISC OS 3.1 filecore image.

Bundled ROM image - as above, a freely distributable version of a RISC OS ROM, probably 3.1.

Conclusion

I am going to pursue this?  Apart from my interest in ArcEm, not particularly.  Indeed, there isn't a great deal of technical detail here that isn't already being taken care of.  This might be a chance for someone to get off their rear, I as talked about previously. Whilst we're on the topic of emulation, I'd like to correct a recent drobe article on mentioning various emulators.  It mentions that the work by Nick Burrett and myself on RISC OS emulation in QEMU (as contrast to hardware emulators such as ArcEM and VirtualRPC) could be used in ArcEm.  In truth, this makes little sense - the QEMU work was an effort to emulate RISC OS APIs - something that has value, but cannot really provide anything close to a comprehensive emulation environment.  In the scenario in this article, the ROMs provide RISC OS itself, and emulation is of the hardware - a much more practical prospect.  What remains true is that integrating the QEMU engine into ArcEm (which was also used by the referred to project) would greatly improve its speed.

If you do wish to pursue this, then good luck.  If you need some advice, then by all means contact me.

I'm of course referring to the recent article on drobe. I wasn't going to comment on this originally, as I felt it was a somewhat shallow article, intended only to generate some journalistic controversy, without conveying anything particularly new.

However, some of the comments are worth responding to in detail, as there's still a huge gap in understanding by users, especially the most vocal ones, in what's involved in software development. This is despite numerous essays on the topic by myself, and endless demonstrations from various quaters on what does and doesn't work.

And despite Andrew Hill's objections, both NetSurf, and all my projects and several other RISC OS projects use identical development models. I won't go into the details of why - I've mentioned it enough before. But the model is open source, collaborative development, minimising effort by reusing systems. This is something we know works, and works exceptionally well - we only have to look at GNU, BSD and Linux for that. It is no accident that we use the same model, the same tools, the same software and the same libraries. Few other approaches are viable for such large projects in a market with so little cashflow.

Even if we look at Martin's developement of ArtWorks, despite being commerical, it is not so different either - skilled development, building upon years of development, and adding several years more. People seem to forget that NetSurf has now taken around 4 years.

Sadly once again, John Cartmell has insisted he has valid commentary on this subject, despite repeatedly demonstrating he has no authority or experience on things which he tries to demonstrate an opinion. Yes, the repetiion in RISC OS is unfortunate - but it's not the application level at which it is the problem. I refer you to my previous article on this subject. The only thing more discouraging when developing RISC OS software than the technical difficulties involved, are false prophets like Mr Cartmell and a small number of his cronies who actively seek to mislead and and misrepesent the real problems that RISC OS has and the work of the people who really are doing things to solve them.

Let's get real. Software development can be hard. Sometimes really hard, and even if it's easy, sometimes it takes a very long time. RISC OS users are often either unwilling, or unable due to numbers,  to provide sufficient funding for more than a very small number of projects. And RISC OS needs lots and lots of these projects to even be considered seriously by the outside world. Only druck's comments on the article in question reflect the situation in any kind of accurary or detail.

Historical RISC OS development has been short-term hole plugging. That's part of the reason there's so much repetition, and little focus on long-term development. We can partly blame Acorn for that, and partly the rose tinted spectacles worn when we view our "superior" OS, which even persists today.

I've said it before, and I'll say it again, because it bears repeating. Firefox wasn't a single project. It was a collection of related projects - GCC, UnixLib, porting tools, ChoX11, autobuilder - all projects under the above mentioned collaborative development model. Moreover, all projects designed to significantly reduce - I'll say that again: significantly (I'm talking orders of magnitude here) - the effort involved in developing new software, and especially to allow conversion of software from other platforms.

And why? Because that was the most practical way to achieve what users wanted - bringing high profile open source technologies to RISC OS that users are so good at going on and on about.  But not in the short-term way I mention above.  Not in a "port and forget" way that's been traditional of some conversions to RISC OS.  But rather in a way that means that any technologies developed or improved for the port could be reused for new ports, and reduce their "time to market".  And in a way that new versions could be generated very easily, in a predictable, repeatable fashion. 

Ultimately, we can only provide the methods and the means.  The motivation must be there also.  For developers, this means finding some reason to bother continuing - whether it be financial or otherwise.  Certainly it doesn't include putting up with the cronies.  For users this means getting involved and adding something positive to the process.  It doesn't mean the slacktivism that's sadly prevalant in the RISC OS community, where slagging off someone and having a strong but basless opinion is somehow considered a worthy contribution.  I don't mind strong opinions - I really don't.  And even if I disagree with it, I'll respect it as long as it has some kind of justifiable basis that you can point to.

Forget "ransomware" or whatever other term you want to apply.  That's not the point.  RISC OS needs focus.  If there's focus, then funding and the means to bring it about can be found.  At present, RISC OS doesn't have very much focus.  It and its users often don't understand  or can't decide what applications it needs, and even when it can, those answers are naturally reactionary, as it tries to match facilities found in Linux, Windows and Mac OS X.

As for actual development, bear in mind that the number of people able to do significant amounts of it due to time or skill constraints is very small, and isn't going to be replaced very fast if they decide to leave due to a perceived lack of focus, or being fed up with people talking our their arse.  Much of the specific technical work will naturally come from them, but I'll again repeat something I've said many times before.  Get involved.  Find ways to get involved.  There's a greal deal to do that anyone with a little imagination and some free time can do.  One irony is RISC OS users have a significant proportion of those who might in fact be expected to have free time - the retired.  I'll be providing something in the next few weeks which may be one step in this, but  it's really up to the users to  do this.

So, the moral?  RISC OS is in trouble - more than it has been in for some years, and 2005 may have been a peak in appication development unless there's an attitude change.  And that will need to occur first before we can talk about funding software, or development models.

As many of you know, there were a number of personal changes during 2005 for me, not least of which was moving country. What probably won't surprise you is that I now how much less time, and will probably never be able to repeat the time I dedicated to RISC OS last year.

Because of this, I believe changes are in order to try and be fair and equitable, especially to subscribers who continue to support the project, and are not presently getting much for their contribution. From today, I'll be indefinitely extending all existing subscriptions, including a number of unprocessed subscriptions back to the South East show in October, and will not be taking any new subscriptions.

Indeed, since PayPal requires closure and reopening of accounts in order to move country, I'll be cancelling all subscriptions handled through their system and the project address.

The good news is that no subscribers will be expired from the project itself, the mailing list will remain open for support issues, and where possible, development will continue.

It is intended to relaunch the project much later in 2006, and you'll probably see some changes in a lead up to that, as well as addressing a number of the shortcomings that presently exist such as the timeliness of processing subscriptions, along with a less complex (and cheaper) pricing model.

I hope this change is the best way I can be open, honest and fair, whilst remaining realistic about the project. If you have any individual queries about your subscription you can mail unix@chocky.org, and I'll be happy to come to an arangement. The last thing I want is to find the project to find itself in a situation like the Select project, where it has dedicated but frustrated supporters who are not seeing any visible output.

Thanks for your support in 2005.

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.

Have I been nominated for this on drobe.co.uk this year? Sadly not. I hesitate to guess why Chris has chosen to exclude me, since his public reasons have at best, been rather confused and contradictory.

Am I being petulant for making a noise about this? I do not think so. No doubt most people will remember me in 2005 for making Firefox for RISC OS available, but the truth is that the total of what I did in 2005 for RISC OS was very large indeed. No doubt there will be some people, as always, who disagree with what I say, or say that I'm banging my own drum. But I'm also regularly told by others that I'm modest about my work, so there is unlikely to be any general agreement there.

As for the "Best General Contribution" award on drobe, I avidly believe that this is a title which belongs to me for my work in 2005. In 2004 I was runner up to Martin Wuerthner - something that I gratefully accepted and was certainly justified for Martin's work on ArtWorks and other areas of RISC
OS. Had there been a 2003 award, it perhaps would have gone to Justin Fletcher.

For 2005, I'd like to recap the year - a year in which I spent around 50% of my time contributing to RISC OS. And since the award nominations were published on Xmas Eve, that's also where I'll start in 2004.

Specific Events

Chrismas Day, 2004

During December, I had asked for suggestions for games to port for a Christmas release. The winner was Battle for Westnoth, but I also released ScummVM, and building on my work, GLHack, LinCity and SuperTux ported by others. Many of these can easily have their latest version built by relatively untechnical users because they were contributed to the RISC OS autobuilder.

Also on the same day, was a release of GCCSDK, which is the framework for development of the GCC port to RISC OS. This was version 3.4.4, which once again showed substantial improvements over previous versions in terms of the compiler itself, the C library UnixLib and supporting tools. This was to be the first of 3 releases during the 12 month period.

January

During January, I reorganised the content of riscos.info, moving all my RISC OS specific content to it. Not very exciting perhaps, but it made information a little easier to find, not having it spread over chocky.org.

January 3

I discussed the behaviour of libraries under RISC OS and interaction with the C programming language and GCC and why RISC OS lags behind other platforms in this area. Sadly, much of what is discussed in this article - especially the shared library aspect - has yet to be released in a public form, although it is crucial to the future of RISC OS.

February 26

I attended the South West show, driving around 5 hours in each direction in the ice and snow. Apart from hinting at browser developments for later in the year, I had secured a large number of RiscPCs and other Acorn parts from an ex-Acorn employee who was cleaning out his garage. This enabled me to furnish some users with cheap machines, network cards and a variety of other hardware.

March 3

I wrote about Automatic building for RISC OS - the RISC OS autobuilder, which I had developed during 2004 for the GCCSDK project. This project is important to RISC OS because of the enormous time-saving to developers and removal of error-prone manual packaging and building of ported programs. At this time, over 100 programs and libraries have been contributed, so that anyone with a working GCCSDK setup can easily build them with a single command.

March 12

I announced my intention to bring a port of the popular browser, Firefox, to RISC OS. I asked for pledges to financially support the project, which I knew would involve many releases, and many months and course be relatively expensive for a small platform. The response was not vast, but it was enough to enable me to press on. In fact, I had been looking seriously at bringing Mozilla Firefox to RISC OS since around October 2004, and for around 3 years previously, I had focussed work on improving the technologies - in particular, GCCSDK - that would eventually make Firefox and many other programs like it possible on RISC OS.

March 27

I took over as chariman and secretary of local user group, BAUG, from 13 year incumbent David McDowell. BAUG, which changed its name to CAMRUG at the same meeting, is the longest running Acorn/RISC OS user group, and is also the closest to former Acorn HQ as well as the new Castle location in Cambridge. My position at CAMRUG allowed the flagging group to survive another 6 months, and I was able to arrange a number of interesting speakers to come talk to us including Oregano UK (Richard Brown), James Bursa (NetSurf), Neil Spellings, DJing with RISC OS (Jon Wright) and Dan Ellis on USB (Pace/Castle).

March 31

I took over work done by Nick Burrett on QEMU, a system and processor emulator for Linux.  Nick had done work on QEMU to allow a limited set of RISC OS binaries to run directly under Linux - which proved very useful for testing.  I took his work further, enabling a larger range of programs to be run.  In an article, I talked about improving this work further, including practical steps towards being able to run a limited number of graphical RISC OS applications under Linux.

April 12

Also at CAMRUG, I was able to demonstrate a very slow, but nevertheless, functioning, initial alpha version of Firefox for RISC OS. This "event" brought users from other groups to come check it and us out.

May 6

This was the second release of GCC for RISC OS for this period, bringing more fixes and improvements.

May 21 and 22

This was the biggest show of the year in Wakefield. For many people, this was their first glimpse at the forthcoming, and much-improved although as yet, unreleased, Firefox port. I also demonstrated a number of other programs that made use of the same technology. On the Saturaday I gave a talk about my work and answered questions.

June 1

I again demonstrated Firefox and my other work at the ICENI user group in Ipswitch.

June 17 and 18

I travelled to The Netherlands to the RISC OS show in Nieuwegein. Unhelpfully, on the day of a rail strike, which resulted in an expensive taxi ride. At this show I demonstrated the first beta of Firefox - the very version which was just about to be released. I had asked for pledges to reach 100%, and the show saw it come very close indeed, although it did not reach the precise total until the following Monday.

This show was also important as I was able to travel to Belgium afterwards and spend time with John Tytgat. We discussed ideas for a number of important plans for riscos.info, GCCSDK and other joint projects, which were firmed up later in the year. Some of these ideas are in the process of being implemented now, some are long term, but are vital for the surival of RISC OS development.

June 20

I travelled to London to visit the user group, ROUGOL and demonstrated the beta Firefox which had been released that morning.

July 8

Yet another release of GCCSDK - this is the present release, which is due for an update very shortly, but has done excellent service to RISC OS developers - new and seasoned developers alike.

This release of GCC was in many cases a watershed. It was the first release of GCC for RISC OS to have C module support - a feature which the commerical Norcroft had always had, and users had long asked for in GCC. Additionally, benchmarks showed that GCC could generate substantially faster code (albeit with a slower compile time) than Norcroft. These features along with it being freely available, made it the first choice for any RISC OS development, since GCC could match and in many caes, excel, features found in Norcroft.

August 6

I outlined in an article some of my frustrations with constant repetition and waste of time evident in RISC OS developement and RISC OS itself. RISC OS continues to suffer from "not invented here", where people rewrite their own versions of applications, libraries and other things instead of collaborating and solving some of the serious application problems that RISC OS continues to face.

August 27

I announced an address change for Unix Porting Project subscriptions because of an imminent move of country - this continues to be handled by Mark Stephens who has done a great job. At this time I naturally also handed back the adminstration of CAMRUG.

September 13

After numerous people had suggested various bits of ARM hardware for RISC OS to be ported to, I wrote an article which discussed why in most cases, it simply wasn't sensible - often for financial reasons. This article reached a wider non-RISC OS audidence.

September 27

After some sadly blunt and insistent (but wrong) speculation on usenet, I updated an article from 2004 which talks about the RISC OS filetype system and its representation on other filesystems, especially network oriented ones. This article demonstrates a number of (easily fixable) shortcomings in a variety of RISC OS filesystems, as well as the follies in using "notypes" and anything but a default filetype of text.

October 5

I wrote a review of VirtualRiscPC, which I use for RISC OS on an x86 laptop. I identified a number of shortcomings which sadly are still to be fixed, but which I hope that VirtualAcorn will soon address. VRPC continues to be the only way I can use RISC OS since I still do not have my real machines.

October 10

I wrote an article about the practicalities of open sourcing parts of RISC OS. This article discussed the pros and cons of various approaches as well as the legal and technical problems involved and some blue sky speculation about how ROL/Castle might "open up" RISC OS. This was one of a number of my articles in 2005 which received wide readership outside of the RISC OS community, creating a greater recognition for the platform, especially on OSNews.com.

November 3

Negotiations during the previous months with Aleph1 enabled me to secure the release of the sources to the PC Card software - the software that controls second process x86 cards and podules in RiscPCs and older Acorn machines.

November 7

I outlined problems and the endless repetition with the RISC OS systems for formatting devices. The current setup is wheel reinvention with a formatter per filesystem.

November 12

I made easily available sources to GCCSDK for Cygwin (i.e, RISC OS development under Windows) and the latest versions of the Firefox port in order to encourage development by people other than myself. Sadly, this release seems to have been entirely without any result.

Also During 2005

DeskLib

In order to maintain a useful, comprehensive Wimp library for RISC OS, DeskLib was updated a number of times, although it only received one formal release. DeskLib underpins Firefox and many of my other ports as well as a multitude of other RISC OS programs.

ChoX11/libSDL

Both Alan Buckley and myself were busy at work on these two libraries which provide the translation layers to allow graphical ports to interface to RISC OS. ChoX11 replaces the X system for X-based Unix programs, using DeskLib to talk to the Wimp. libSDL is used for many games ported by Alan, Neil White and myself.

Mailing List/Usenet Help

I don't have an exact count, but on possibly several hundred instances during 2005 I provided help on the comp.sys.acorn.* heirachy and various RISC OS mailing lists to numerous problems. In some cases, only a small number of people were able to accurately answer questions including druck, Martin W. and myself. Unfortunately, a group of people made 2005 the year in which they would endlessly spread misinformation and troll, only to confound and frustrate people trying to provide clear information. Ultimately, RISC OS users lost out.

Firefox

I provided 5 beta releases of my port of Firefox to RISC OS. And although none of these could be described as a full and reasonably bug-free release, each version has been faster, more stable and provided access to numerous websites which were previously impossible on RISC OS. Stability problems remain in the current beta 5 release, although those specific issues have been fixed locally. Work continues towards the next version.

Sadly, not nearly as much work as I would have liked to have carried out on Firefox has been done - bluntly, for purely financial reasons. The project was only supported by a limited proportion of RISC OS users, and only contributions by Alan Buckley and the GCCSDK developers have done work which has even indirectly helped its development, so it is likely it will continue to suffer slow development in 2006. As it is, even though the project gained me an enourmous amount of valuable experience in a variety of areas, it cost me dearly financially, and I would have done myself a great injustice to spend more time than I did on it.

As it is, I believe that the fact that I was able to do the work at all nothing short of a miracle.  For comparison, look at the AmigaOS effort - that has a whole team of developers, as well as a sizable bounty but has yet to release anything substantial.  That platform too, has suffered greatly from infighting and finger pointing.

Indirect Work

The drobe.co.uk awards mention a number of projects which have benefitted RISC OS.  Certainly those projects deserve recognition in their own right and from the considerable efforts of their developers, but I must point out that many of these rely on work I had previously done.

CocoGnut

Marc's Gnutella Client.  This relies on DeskLib and I was able to advise Marc on aspects of use of GCC, DeskLib and other C issues.

NetSurf

NetSurf continues to prove my point that a program as complex as a browser is simply not practical to be produced commerically for such a small market - further demostrated by the lack of appearance of the commercial browser, Oregano 3.  And given wider developments outside RISC OS, you might even argue that it's not practical at all.  NetSurf, as an open source product is updated almost daily, providing lightweight and fast web access to many websites not possible under previous browsers.  Much of its underlying technology is shared with the Firefox port., and although I have not contributed directly to the NetSurf codebase, I regularly converse with its developers, and I can say in all truthfulness that it would not have been practical for the developers to do without the previous work of mine on GCCSDK and porting tools.

OpenTDD

This game was directly portable to RISC OS because of the work done by Alan and myself.  There are many similar games which could also be converted because of our work.

Sourcery

This of course relies upon GCC and its bundled tools to provide a powerful GUI development environment

SunFish

Alex Waugh's great NFS client.  I did not contribute to SunFish in any practical way, but I mention it because it was the driving force and testing ground for adding module support to GCC.  In fairness, most of the very hard changes to GCC for modules were made by Nick Burrent, but all GCCSDK developers contributed to it coming about.

Conclusion

That's all I can think of right now.  Perhaps there are other things I've forgotten, but I believe any reader will get the idea.  2005 was an exceptionally busy year for me, and I believe the above demonstrates my commitment  and contribution to RISC OS in 2005.  As it is, I am deeply disappointed that I was not named in the contributer of the year category on drobe.co.uk.   You are of course welcome to contact Chris at chris@drobe.co.uk to redress this situation, although I suspect it will take some persuasion.  Perhaps it is also true that a re-run of the poll now, would not have a favourable outcome after my protest.  But I cannot let this go uncontested, and do not let there be any confusion about what I have done in 2005.

As usual, little is ever fair, and how much I can be bothered to contribute in 2006 remains to be seen after such a slap in the face.  Certainly I will have much less time next year, and I'll shortly be announcing neccessary changes to the Unix Porting Project so it can continue at all.

Peter Naulls, RISC OS Contributor.

No, this isn't an ill-defined rant about why Castle ought to open source RISC OS - there's little advantage for them to do so commerically, no matter how much people might like it to happen, even if they were in a practical position to do so - and I don't believe they are.

What I'll instead argue is that certain parts of RISC OS ought to be open source. Crucial parts that affect all users, even if they don't realise it, parts that can be created from scratch and made much better than the Acorn original, and parts which can managed by specific developers who already understand them well.

Freedom and Software

I'm not going to evangelise about free software or about the meanings of free - if you want that, then I suggest a visit to the Free Software Foundation webpages and perusal of their essays. What I will say however, is that certain aspects of software development may be too important to leave to specific companies with traditional closed-source methods, especially in a small market.  I've argued this before with RISC OS web browser development, where RISC OS has seen a string of commerical browser development which has then stalled or stopped when the company changes focus or vanishes - and we're sadly still waiting for Oregano 3.  Contrast with the open source browsers on RISC OS - NetSurf and Firefox - which although both have some way to go before becoming fully polished products, remain accessible for anyone to have a go at improving, even if the original developers move on.

RISC OS and its components

As you probably know, RISC OS is built from numerous components, or modules which together form the core of what we know as RISC OS.  Other modules may be loaded providing additional functionality such as drivers (networking for example) or other general functionality (toolbox modules are an example here).  In some versions of RISC OS, these modules may replace versions in ROM with newer soft-loaded versions.

Additional parts which form other parts of RISC OS include various applications and utilities in the boot sequence such as the confiugration application as well as other various bundled items.  These are of lesser concern in this article, but still relevant.

Open Sourcing

So what I am driving at?  A real example will help.  Recent discussion on usenet revealed that the SharedCLibrary bundled with the A9 version of RISC OS as supplied by RISCOS Ltd. lacked various features included in the 32-bit version supplied by Castle and was required to run a variety of modern applications. There were suggestions that for political or other reasons Castle might be reluctant to make such a version available.

In practice, this particular issue seems to now be all but resolved, however what if it had proved to be commerically impractical?  This might have called for development of a "SharedFreeLibrary", which provided the crucial functionality of Castle's SharedCLibrary in an agnostic way to all versions of RISC OS.  Such a version could have code contributed by several parties for the benefit of all.  Indeed, most of the code already exists in UnixLib for such a project to be put together in a relatively short period of time.

Following in Footsteps

It might not surprise you that there are precedents for this suggestion.  Examples include free versions of DDEUtils (DDEUtilsCy), Acorn stubs (GCC stubs), Window Manager (Wimp2), the Freenet internet stack, as well as a handful of items that were made available before some of the utilities in RISC OS were converted to 32-bit.  Also don't forget things like Justin Fletcher's multi-tasking error boxes and a long list of desktop hacks that overrode or augmented existing behaviour.  On the other side of the coin, we also have the Printers+ project, which had contributions by the late David Marston.

What I'm not proposing is an all-out replacement of RISC OS functionality with random bits of code, like the ill-fated and poorly considered frx project.  Rather, a more structured approach, making good use of limited developer resources and choosing carefully components that might add value to users and RISC OS companies by having an open source implementation.  With such components, both third party developers and RISC OS companies - Castle, ROL, A6 and perhaps others could contribute code and then be able to freely use the result (subject of course to licensing). Users would enjoy a homogenous version across versions of RISC OS (although perhaps requiring a base version of RISC OS like RISC OS 4) and developers would benefit from being able to rely on features which were certrain to be present.

I appreciate that this is something of a utopian view, and in the real world is constrained by time, effort and commerical concerns.  Nevertheless, I'd like to propose some projects that might benefit from this approach.

Select Features

The current raging RISC OS debate is the availability of Select/Adjust features on RISC OS machines, particularly on the Iyonix, especially since the latter is what it appears that a considerable proportion of active RISC OS developers now have (on which Select presently only has a small subset of features and which aren't publically available) versus RiscPCs which many have stopped using (on which Select is a full version of RISC OS in its own right). 

To at least start to address this, as well as RISCOS Ltd's apparent reluctance to persue Iyonix developement, there's no reason why at least some Select features couldn't be provided in part by open source implementations.  To start with, some of the new APIs, especially those dealing with graphic effects, would only need to dummy functionality.  I appreciate too, that Select on the Iyonix does require some kernel-level changes, but given code that is "ready-to-go" and the correct information, there's no reason Castle couldn't be convinced to make these changes.

Allow me to stress that there's some degree of speculation in what I've named above.  I'm not familiar with most of the specifics of the Select changes, and am not in a position to name features which might be suitable for such treatment.  But there's another side to this theoretical situation:

Instead of ROL's existing subscription scheme, they could instead contribute and open source code (it would of course have to be code that they had full ownership over) to this project.  This could be done on a bidding/pledge arrangement where certain elements were made available piecemeal when the required level of financing was met.

And is this situation realistic?  Perhaps it is a bit too egalitarian for the sometimes conservative RISC OS market.  I'll let you decide.

Not Done Yet

What else could benefit from this treatment?  How about fixing the CDFS/ADFS/SCSI mess I named in a previous article?  I suspect this could become complex with the addition of USB in RISC OS 5, but it could be done.  This would also mean people could freely add support for various optical drives (and adding DMA support), instead of reinventing the wheel.  FileSwitch too, perhaps - addressing the 2GB limits.  This is all very easy to get excited over, but remember that often there are sobering interactions between various parts of RISC OS that may not be at all obvious from external examination.

Summing Up

I don't have to point out that Open Source is a powerful tool - there's plenty of evidence for that already.  I don't think either that it's silver bullet for the multitude of RISC OS woes - many of which still come down to lack of applications and application features - but there might be common ground using it for developers and RISC OS companies to at least start to
look like they're all moving in the same direction.

I've now been using VirtualRPC for around 2 months.  I felt it was time to look at its pros and cons in detail, and mention some of the issues that don't seem to have been aired elsewhere.

So, is VRPC a useful product - yes, there's no doubt about that.  But is it professionally executed, and a practical substitute for a real machine?  In my opinion, no - read on to see why.

This is an extension of a previous article where I discussed filename handling on foreign systems and in particular, how RISC OS filetypes ought to be represented on systems which do not no nominally support them.

This last point is still a matter of confusion for some people.  This has been compounded by bugs in some filesystems which do not implement the system I described properly, and also by misinformation that has been given in certain instances.  In this item, I will try and enumerate all the RISC OS filesystems and programs that deal with the issue of handling RISC OS filetypes and document how well they perform. I will stress that some of this information is from memory as I do not have immediate access to all of them, but I have checked where possible.  I would appreciate any corrections or additons.

The Filesystems

AcornNFS - I don't have access to this so can't comment on its implementation, but I understand it is the only RISC OS filesystem that implements a method of representing untyped files with an extension to the ,xxx system. Normally, this feature isn't used in modern RISC OS usage, as untyped files are quite rare and not that useful, and I don't judge its loss in other implementations as a failure, but it might be useful in some instances.

SunFish - This implements all aspects of the system fully.  One thing it can't always do, and this is because of NFS itself rather than SunFish is follow symlinks as they may point to outside the mount.

LanMan98 - This also implements the system correctly.  I strongly recommend you do not use its "notypes" option. In some instances this may appear to work more correctly than without, but what's really happening is that it's masking issues.  notypes won't allow you to change filetype and it can display ,xxx extensions at the RISC OS end which is almost never useful.

LanManFS - This is mainly in reference to the version bundled with RISC OS 5.  I don't believe that LanManFS always gets the filetyping right.  Sometimes it appends the ,xxx when it shouldn't be. In addition, it has a fixed buffer size meaning it might not display all the files in a large directory.  I've also seen it have issues with certain filename characters causing confusion.  I recommend using LanMan98 or SunFish instead if you can.

HostFS  (VirtualRPC) - HostFS has two options for filetype handling, neither of which are particularly satisfactory.  One option always adds the ,xxx and other acts like "notypes" in LanMan98.  Its default filetype is also incorrectly set to data rather than text.  If you're only looking at files you've created from within VirtualRPC, then the first option will work ok, but once you start accessing files transferred onto the host system or created there, then you can quickly run into problems.  Note that HostFS is also used for VRPC's CD access.

ImageNFS - I don't have access to this, but I understand it behaves correctly.

DOSFS/Win95FS - To the best of my knowledge, none of these understands the ,xxx system.  However, they can make use of a free FAT field to store the RISC OS filetype if it's changed on RISC OS.  This generally works just fine.

CDFS/CDROMFS - Again, these do not make use of the ,xxx extension (except when viewed by a remote system which does like NFS), but there is an extension to the CD format which can store the RISC OS filetype.  Usually, however this is not used as the mime mapping from the extension is sufficient for CDs, or RISC OS files are put in zip files on the CD.

SparkFS/Zip files - The zip format too contains an extension to contain the RISC OS filetype if it's set.  SparkFS itself does not make use of the ,xxx extension, although I don't know if any of the other RISC OS zip extractors do.  The single change I make to my SparkFS setup is to make the default type text rather than data.  This is because of reasons I outlined in the article above, and can make somethings work more smoothly.  For creating zip files on a foreign system, GCCSDK contains a modified version of InfoZip which can optionally turn the ,xxx extension on (for example) the Unix filesystem into the filetype in the extra zip field, and strip it from the filename.  There is one potential ambiguity however - filenames which have more than fullstop in them (i.e, a Unix/DOS extension) and with no ,xxx extension get an explict RISC OS textual type for consistency.

UnixLib programs - most UnixLib programs don't have any need to make use of this system, although there are some exceptions such as John Tytgat's port of CVS.  We made very sure that UnixLib implements all aspects properly where relevant, since getting filename handling correct can be crucial with Unix ports.

Linux ADFS - When mounting an ADFS filesystem under Linux, the RISC OS filetypes are ignored. However, I did make a modification which allows the ,xxx extensions to be concatenated where appropriate.  This can be handy when viewing the exported filesystem on a real RISC OS system.  This change should be usable in the Iyonix Linux kernels.

Messenger/Pluto - For attachments, these mailers will need to make to make a mime match back and forth.  I don't have Pluto, nor the latest version of Messenger, but I believe that in most instances they do it ok, but the default filetype is not text, which may cause issues.

Conclusion

I hope that that's reasonably comprehensive.  If you've any additions or corrections, I'll be happy to add them in.