RISC OS

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.

It's now three years since I picked up Iyonix #12 at Castle's developer day in September 2002, which was shortly followed by its official release in October of that year at the South East show.

So, what's happened in those 3 years, what's still to be done, and why are some people still holding out?

We often see both dyed-in-the-wool RISC OS users and outsiders suggesting that RISC OS ought to be ported to some ARM board they've just spotted.  Typically, this is some low-cost ARM9 or PXA-based PDA or perhaps a networking device. There are certainly some examples of this in comments made in articles on this blog, as well as this questionably RISC OS related item on IconBar.

Of course, it's all very easy to suggest that RISC OS ought to be ported to these things, and in most cases, the stock answer of effort and expense is the correct one. But why is this the case?  Surely we can just hack up a new version of RISC OS with the right drivers and have it just work on a shiny device. In practice, no - and I'd like to discuss why.

An ARM device

For the purposes of examing a real example, I'll consider the AirLink AR315W, an inexpensive wireless router that I picked up to use in its own right for my networking requirements. My choice of this device came down to price - around 16 UKP after P&P - and also an article on linuxdevices.com showing that it could be hacked to potentially run Linux or other OSes. Sadly, the page the article refers is now unavailable, but we can see that it contains an ARM9 Marvell part.

So could RISC OS be ported to this device?  In principle yes, as the existence of a Linux port demonstrates that sufficient information is available to develop drivers and provide other low-level information. The value of RISC OS on something without a display or input devices is perhaps questionable, but as we are examining this question in a slightly wider context of ARM devices in general, we'll ignore this detail. 

From the point of development, the amount of effort to convert RISC OS to a given device is quite large.  Unlike Linux, which has drivers for a vast range of hardware and has probably been ported to a similar device to the one you intend to target, RISC OS has only been targetted at a small number of devices and drivers.  This means a great deal of effort to develop new drivers from scratch.  HAL or no, this is lots and lots of programming.  If RISC OS were open source, then it's possible someone might be able to justify this as an enthusiast effort in their spare time, without having to answer to anyone.  But this is unlikely to happen any time soon.

It's true that you could obtain the source from Castle for development/evaluation purposes for no charge, but probably you would have to present some kind of business proposal to make it worth their time - and yes, it would be quite a lot of time to prepare what is essentially a software release, plus various legalities and other hoops.

I'll throw one further issue into the mix.  With unfamiliarity with such a large body of code, I would predict it would take myself, with my experience of operating system development, around 6 weeks to become comfortable enough with the code to start to be in a position to make the substantial changes required to port to a new system.  Vary that time as you see fit for different levels of experience.

A Real Product

So the problem now is that to justify the substantial time and effort to bring RISC OS to a new system, what's really needed is a proper product plan.  And likely to make any kind of financial sense, you'll have to sell at least several thousand of the device, if not more.  On top of that, RISC OS needs to make more sense on the device than competing options - we'll return to this point in a moment.

This is a problem which has plagued development of a RISC OS laptop.  It has been suggested that to make a viable product, around 1000 would have to be sold.  That might be possible with a cheaper desktop product such as the Iyonix (which also has applications outside the enthusiast market), but a laptop simply wouldn't have the same demand.  This is the major problem against a RISC OS laptop on top of all the other issues such as sourcing an appropriate case.

Suitability

Returning to the wireless router (which incidentally, I can certainly recommend after a firmware upgrade which fixes a connection dropping problem), and networking products in general, would RISC OS make sense over Linux or a custom embedded OS?  Probably not - once you have your Linux kernel port, it becomes very easy to arrange NAT, routing, wireless operations, DHCP, firewalling, a simple web server and everything else it does with a handful of commands on Linux.  True, some of this does exist on RISC OS, but much of it doesn't, and would be effort to add to the TCP/IP stack or port and hard to reach the same degree of flexibility in this area.  There isn't much competition here.

When RISC OS makes sense

Not to put a complete damper on all efforts, but there are clearly some instances where RISC OS does make sense on new ARM hardware in the shape of the Iyonix and the A9.  In these cases, the respective companies have software and solutions that work well for them and their customers on RISC OS.  Perhaps they have something that simply doesn't exist on Linux for practical, legal or political reasons or where space really is tight and a cut-down version of RISC OS is just the ticket.

So what should we expect to see RISC OS on?

That's a difficult question to answer of course - I have no idea of the plans of any of the RISC OS companies or the demands their customers might make.  What I can say is that I do expect to see RISC OS on more devices in future, but because of the reasons I've outlined, they're likely to be few and far between.

I'd like to take a look at the uses of Simon Wilson's recent OpenGL port to RISC OS. As you may know, OpenGL is a cross-platform API for 2D and 3D high performance graphics. Many graphics cards support it, including the Iyonix's NVidia card, allowing lots of fun things to be done.

Unfortunately, my Iyonix is currently somewhere in the mid-Atlantic, although I did try an early version of the boxes demo that Simon put together, so I've not been able to try his recent efforts.  However, looking at the Debian packages that mention OpenGL, there are nearly 200.  Many of these are games of course, and there are plenty of obscure libraries, but they may give a starting point for experimentation.

As stated, Simon's work is restricted to the Iyonix, since it's targetted its graphics card, and no other RISC OS machine contains suitable hardware except perhaps RiscPC-enabled ViewFinders which have ATI chipsets but thast requires a whole separate effort.  In principle, it ought to be possible to access native Windows OpenGL functions on VirtualRiscPC, with relatively little effort.  In this way, as I alluded to in my article on RISC OS on x86, RISC OS distances itself from hardware specifics.

In any case, I hope to give Simon's work a spin in future, integrating it into GCCSDK and trying it with some of my ports.  I'd be interested to know if you've looked at in any detail.