In common with a lot of people who used to use RISCOS, I don’t use it now and that is the focus of this article: Why don’t I use it any more and what would it take to make me use it again? Of course, an article of this sort still has worth as there is bound to be some degree of correlation between my feelings, experiences and hopes in relation to the platform and those other people.
This article constitutes both an assessment of the current state of the RISC OS operating system in addition some speculation about its future. The article doesn’t strive to maintain an objective view as, instead, I am documenting my personal relationship with the issue. Make no mistake, this is a ‘me-centric’ and partly speculative article.
Part 1 of the article contains an overview of RISCOS. It serves as both an introduction to some of the interesting features of the OS coupled with some exposition and opinion regarding the current issues affecting the OS.
Part 2 builds on this will some investigation into the issues that stop users such as myself from actually using RISCOS.
Part 3 Is the most fanciful section as I propose some possible, hypothetical solutions that would, for me, make the platform viable again.
Note About The RISCOS User Scene
This is largely an opinion piece and I welcome commentary, criticism and counter-opinion. The commentary for and against the points that I raise really are the thing that makes the effort of writing an article of this sort worthwhile. However, there exists amongst the RISCOS faithful a minority who can see no wrong in anything RISCOS related. I think that I can safely say that, if it were discovered that RISCOS gives you cancer, some RISCOS users would claim that they like having cancer.
I remember reading on a forum in the late 90’s a RISCOS user telling people that he liked the 77 files per directory limit because it encouraged him to organise his files properly. I might add that the 77 files per directory limit no long afflicts RISCOS. Let’s hope that user is still with the platform now that one of his favourite ‘features’ has been removed
Some of these people probably consider themselves part of a back-bone of loyal, patriotic, true supporters of the platform but I hold the opinion that if you are truly a fan of something, you can accept criticism of it. You don’t have to be loyal to something that is genuinely good.
I remember some quarters of the Amiga-faithful of the late 90’s telling everyone that they don’t see the need for more 256 colours, greater than 8 bit sound or access to this new-fangled internet thingy. To me, these users who automatically preferred anything that they were given contributed to the decline of the platform.
Part 1 – Some Of The Features Of RISCOS – for the uninitiated.
The method of multi-tasking that RISCOS uses is called co-operative multi-tasking. In such a system, the main program loop of each running application progresses through a sequence of functions such as checking for user input, refreshing parts of its display and performing performing any processing on its own data. The last function in this sequence is always to return control to the OS. Having regained control, the OS then services the next application.
If you were to run:
10 PRINT “hello world!”
20 GOTO 10
on a RISC OS machine, the entire gui would stop until the application had finished or the user terminated it by pressing
In contrast, other operating systems such as Microsoft Windows and AmigaOS instead employ pre-emptive multi-tasking. Under such a system the execution of such a perpetual ‘hello world’ program, would leave the rest of the system unaffected.
Another problem inherent to co-operative multi-tasking is that, as each app has to finish what it is doing before it can return control to the rest of the OS, multi-tasking is not as smooth as it is on other OSes. Sometimes, a programmer knows, in advance, that the application will need a lot of time for processing. In such a case, on a co-op system, the programmer can split the task up into manageable sections so that the program can periodically relinquish control to the OS so that other apps can be serviced.
For example, an application engaged in a task of image processing that will take 30 seconds to complete, won’t necessarily tie the entire machine up for thirty seconds; one would hope that the programmer would have found a way to split the task up into chunks. However, this is not always the case and this means that, in cases of normal application usage, the hourglass pointer can be system-wide. On other operating systems, one wouldn’t normally expect to be confronted with a system-wide hour glass. If, for instance, an application such as The Gimp presents one with an hour glass, on other operating systems, it would be expected that one could switch to another application while the processing is in progress.
It is actually possible, under RISC OS, to implement processes that run as a ‘background task’ in that they are seemingly un-interuptable processes that do not ostensibly appear to be disrupting other tasks on the machine. A music player would be an example of an application that uses this technique: When the system is in use, user application activity must not interrupt the playback of the music. Most applications of this sort split their functions between an event-driven module (see section on RMs, below) and a WIMP driven front end that controls the player module. The relocatable module operates independently, doing the actual sound processing and periodically filling the sound buffer. At times, the WIMP front end might appear to be interrupted, the counter could stop, but the music will keep playing.
RISC OS doesn’t employ much in the way of memory protection. A crashing app can overwrite the workspace of another app or even of the operating system itself.
This lack of memory protection also makes the OS inherently insecure. Any app could, in theory, look within or alter the workspace of any other application. To people shuddering at this point: hold on to your tin-foil hat, it’s not as bad as it seems! Any exploit that takes advantage of these weaknesses must be coded specifically for RISCOS and as with other alternative OSes, RISCOS simply doesn’t have much of a problem with spyware, trojans or viruses. In truth, RISC OS would have to become about 100 times as popular as it is now before these problems became manifest. Even then, a ploy of some kind has to be successfully carried out in order to get an executable onto the machine.
In summary, by the time that RISCOS had gained an entire percentage of the web access statistics, something could be done to improve security. Something tells me that an IE equipped Windows box is going to suffer greater security problems than the average RISCOS user.
The Icon Bar
Upon launching, a RISC OS application adds itself to the application bar (or the ‘icon bar’ in RISCOS-speak) at the bottom of the screen. Typically, a RISCOS application, when first run, does not open a blank document. If the user would like to start a new document, he or she clicks once on the icon in the icon bar. If the user would like to open an existing document, the user can either, double-click on the document, or drop the document on the icon bar icon. If the user would like to open a .html file in the text editor, the user simply drops the file onto the icon bar icon that represents the text editor.
RISCOS convention dictates that hardware devices such as printers and hard disk drives are placed on the left of the icon bar and applications to the right.
Drag And Drop Saving
On RISCOS, the drag and drop concept is carried over to the saving of files; there is no conventional file save dialogue. The ‘save file…’ option exists as an entry on the main pop-up menu of the application. To save a file, the user first navigates, using the standard file management features of the OS, to the intended destination directory for the file; then, the user, navigates to the save menu, edits the file name and then drops the file into the directory. This usage pattern makes sense from a usability point of view. Often when a user is working on a file, he will already have a file management window open on the desired directory. Further more, the user will often want to operate on other files within that directory.
Drag and drop even works between applications. Having selected some text, a user can import the text into another application by dragging the icon in the ‘save selection…’ menu from one application to another. Where applicable, and supported, the applications can establish an OLE link rather than simply transfer the data.
Nearly all of the OS is implemented as a collection of ‘relocatable modules’. These modules extend the kernel with extra system calls and these functions become available to all user and system programs. As the entire OS is implemented in this way, it is quite simple to upgrade a section of the OS or to add new functions. To upgrade the font system, for example, the user loads the new font module from disk. If the module in question is an upgrade to a module in the ROM, the newer module takes precedence. RMs can be launched at run time from a start-up script, as part of an application launch script, or by the user at any time.
The floating point maths module is an example of an RM. If an application requires FP capability, it ensures that the FP module is loaded. Every time the ARM Microprocessor encounters an unknown instruction it offers the instruction to any co-processor that is present. If no co-processor can handle the instruction, the CPU generates a software exception. In the case of a FP instruction, the software FP module intercepts these exceptions, implements the operation using integer operations and returns a result. When a new version of the FP module is released, the user adds it to his ‘!System’ folder so that all applications can invoke it when needed.
Most of the OS outside of the kernel is implemented in the form of RMs. Even though much of the OS can be soft loaded in this manner, all shipping machines can at least get as far as the desktop in a machine without a hard drive attached.
Compared to other desktop operating systems, RISCOS is very compact and efficient. It doesn’t have a system-wide virtual memory disk-paging system and consequently, all apps are designed to fit into RAM. And on the whole, they manage this very well. In cases where data would be unable to fit into RAM, the applications themselves have to implement their own disk paging system for the data.
Obviously, a 50meg TIFF file takes up 50 megs of RAM on RISCOS machine just like it would on any other machine but on the whole, applications are tiny in terms of memory footprint.
Some of the superior compactness and efficiency of RISCOS compared to other operating systems is the result of technical aspects of the operating system but much of it comes from the, less tangible fact, of the ‘RISCOS mindset’ in that a ‘culture of anti-bloat’ pervades on RISC OS.
The last version of RISC OS to be released by Acorn was version 4. At the time of writing, two companies each develop their own fork of RISCOS 4. RISCOS 5 is the version that Castle Technology has developed to power their own Iyonix workstation (see below). RISCOS Select is the version of RO4 being developed by RISCOS Ltd. Select runs on legacy hardware and on the currently manufactured A9 range of workstations (also see below).
This split has been the cause of much heated debate within the community. Some users argue that duplication of effort is the result of two companies developing independent forks of the OS.
From a developer perspective, it is possible release software that can run on either branch of the fork. The problems begin if they want to release something that takes advantage of the additional features of either branch. For example, if the program were directly connected with USB functionality, it would have to address the two incompatible USB stacks separately. This means extra work for the developer.
I’m going to present a more neutral, if slightly controversial, position on this point: I don’t see what harm having two companies developing RISC OS has actually done so far. Certainly, both companies had to develop features such as the USB stack. If both companies merged, there would be less duplication of effort in areas such as this. But what solutions are there? Would a unified company developing a unified version of the OS make exactly twice as much money? That is what would be needed if this new unified company were to employ all of the same people from both of the old companies.
Both companies are interested in developing the potential for RISCOS to make gains within niche and embedded markets in addition to desktop success. For example, Advantage 6 make a version of their rugged A9 machine (see below) which runs a specially tailored RISCOS Select, is designed to wall-mounted and comes complete with GPS*. In a sense, RISCOS Ltd. and Castle Technology are direct competitors. But in another, they are ‘running mates’, both attempting to advance the acceptance of RISCOS within diverse markets. They are both offering RISCOS based products and services and it doesn’t make much business sense for either company to stop making these products or to merge with the other.
In a way, RISCOS development into these niche markets makes more sense than do attempts to make RO into a Windows-beater in the commercial market. This is a point that I will develop further in the final section of this article.
* Ah, the latest RISCOS development: ‘the wall-mounted GPS’. Always makes me smile to read that. Before, you ask, it’s for use on board ships etc 😉
What It Takes To Run RISCOS
There are two different ways of running RISCOS as your desktop OS – through emulation or by running on native hardware.
The Hardware Option
The native hardware option contains, within it, two further options: to run RISCOS on old, legacy hardware or to buy one of the workstations which are currently being manufactured and sold.
The legacy hardware is very old now. The highest spec ‘Acorn’ branded workstation to be released was the ‘RISC PC’.
Summary of RISC PC on wikipedia – http://en.wikipedia.org/wiki/Riscpc
Upgraded to its maximum specification, an official production machine supports a 233MHz ARM processor. Unfortunately, in this configuration, the processor is hosted upon a motherboard which runs upon a 16MHz front side bus. Another strike against machines of this type and vintage, is that the ARM chips that they support do not implement hardware floating point. Hardware floating point comes into its own with calculation-heavy tasks such as movie and audio playback and encoding and real-time 3D graphics. Making matters worse, the RISC PC class of machine doesn’t include much in the way of graphics acceleration; there is no bit blit acceleration for example.
Third party upgrades have attempted to side-step some of these issues by offering local memory on the processor card and the possibility of adding a standard AGP graphics card, via an adaptor. These upgrades alleviate some of the problems of the platform but they can’t push it to the standards of sheer calculative and media manipulation horsepower that current-technology workstations enjoy.
Many of the applications and the OS itself work remarkably well on the old hardware. However, the machine is incapable of, within currently acceptable standards of performance, running a full-featured web browser, running modern 3d games or playing back full res video.
There are, I’m sure, people still performing a task such as ‘writing a letter’ on a C64 with add-on 5.25inch floppy disk drive and dot-matrix printer. However, I’m not willing to use a C64 as my main workstation for these tasks even though it might, technically be possible. For the the same reason and for the purposes of this overview, I’m not going to pay much attention to these older workstations.
Two RISCOS capable workstations are currently available for purchase.
Both of these machines use current generation ARM processors that do not have a 26bit compatibility mode. This means that neither of these machines is backwards binary compatible with most older software. This might at first sound like a disaster but it’s not as bad as it sounds. Firstly, as they run newer versions of RISCOS, older programs can be recompiled without a huge amount of recoding; nearly all current apps are released in a ’32 bit clean’ version. Secondly, a software emulator called Aemulator exists and this allows a lot of legacy software to run, unaltered and seamlessly on the RISC OS desktop. As the machines are much faster than the older generation, the performance of running an older app within the emulation framework is mostly acceptable.
The ARM processor used on these two workstations also suffers another problem: Lack of either multimedia extensions or a hardware FPU unit. So, in terms of raw multimedia processing or real-time 3d graphics power, the chip is less capable than, for example, a Pentium III processor of the same speed in MHz.
In their favour, the processor in either machine is passively cooled and draws a remarkably low amount of power.
Castle Iyonix – http://www.iyonix.com/
The Castle Iyonix has, as its basis, a custom ATX MB. The shipping configuration of the machine offers standard PCI slots, USB 2.0 and on-board IDE. The processor is a 600MHz Intel Xscale ARM processor. The graphics support is provided by either an NVIDIA Geforce 2 MX or FX5200 PCI graphics card. Unfortunately, only some of the available acceleration potential of this NVIDIA card is made available to RISCOS.
An experimental port of the BEOS Mesa Open GL driver has been completed so, it would seem that there may be some hope for 3d accelerated graphics on the platform in the future. See – http://www.simonrules.com/iyonixmesa/
Complete workstation packages start at 799 uk pounds.
A9Home – http://www.advantage6.com/products/A9home.html
Recent user review of the machine – http://www.iconbar.com/comments/news1090.html
In order to avoid direct competition with the already established Iyonix, Advantage 6 have innovated in a different direction. The A9Home uses an unusually compact form-factor. The website lists the case dimensions as: 6.6″ x 4.1″ x 2.1″. That’s considerably smaller than a Mac Mini for example.
The fact of the machine’s compact nature has forced upon the designers the need for some compromise in terms of expansion and capability. Internally, the A9Home supports neither an optical drive or expansion via PCI slots. The computer has sockets for Ethernet networking and audio input and output. Further peripheral expansion is provided by USB slots. Another limitation is present here as the USB support is only 1.1 and there is no obvious way that this could ever be overcome. This means that devices such as pen drives and external CDROM drives can be connected to the machine but that they will operate at a greatly reduced speed. Internally, A9home is fitted with a 2.5” 40meg hard drive.
Some users of early beta versions of the hardware were met with a surprise when they attempted to upgrade the DIMM memory in the single available slot as the supplied DIMM is not simply a memory module, it’s a complete system on a chip, encompassing the ARM processor as well as 128MB of ram! To users of other platforms, the un-upgradable 128MB of RAM might sound like a large limitation, but due to the compact nature of the OS and the applications, 128MB is adequate for normal use.
There exists a fully licenced commercial software emulation solution for running RISCOS called VARPC.
Review – http://www.drobe.co.uk/features/artifact939.html
This commercial software emulator runs on top of Windows. This emulator employs a JIT run time recompilation technique and for general use, on a current PC, it is capable of exceeding the performance of either of the hardware workstations.
By running RISCOS under software emulation, the user is giving up some of the benefits of RISCOS’ ROM based nature. Firstly, RISCOS machines boot and up shut down a bit faster than Windows. Secondly, on real RISCOS hardware it is almost impossible to corrupt the OS as it exists within ROM. In the case of running an OS via emulation, the stability is only ever as good as the security of the host operating system. RISCOS may be somewhat free of malware problems but if Windows becomes unusable for any reason, RISCOS becomes inaccessible.
Part 2 – Barriers To Adoption
Lack Of Essential Applications
Many classes of application that most computer users would regard as essential are under-represented, if represented at all, on the RISC OS platform.
There are a number of web browsers available for RISCOS. Unfortunately, none of the available web browsers can offer a complete, feature-rich web browsing experience that would be in keeping with the expectations of the modern user. One browser might suffer from poor performance and lacking OS integration while another might offer reasonable performance and native OS integration but be comparatively feature-poor. Most users who use RO for browsing do so by switching between browsers while surfing.
Peter Naulls has attempted to alleviate the browser shortcoming by porting the popular Firefox web browser. This project is ongoing but shows promise. Find out more about the project by clicking on this link http://www.drobe.co.uk/riscos/artifact1747.html. Peter Naulls is a well known figure on the Acorn scene and has a track record of doing what he says he’s going to do.
It’s hard for me to imagine not being able to use my computer for video playback. As a keen wild-life enthusiast it’s often gratifying to be able to watch the latest nature documentary covering a subject such as the life-cycle of the noble platypus. OK, I admit that the preceding sentence was untruthful as I have no interest in nature documentaries – let’s just say that it would be really inconvenient not be able to able to watch movies back on the computer. Look, I know what I’ve been doing, you know what I’ve been doing, you probably do it too 😉
And there are some quite legitimate uses for movie playback. Apparently.
RISCOS isn’t just an ‘alternative OS’, it’s a ‘minority OS’ too. This means that it doesn’t have the rich palette of software tools that an alt. OS such as Linux has. A lot of the basics are there but there are some glaring holes as well as some smaller, more subtle ones. If RISC OS were to be my main OS, I’d either have to change what I use my computer for or I’d have to switch over to another machine for certain tasks.
In summary, RISC OS lacks applications because it isn’t popular, and on the other hand, its lack of applications is a barrier to more popular adoption.
Entry Level Cost
The cost of entry to the platform is high. The current workstations are very expensive when compared to Linux, Windows or Mac workstations. This is, in part, due to the low volume nature of native hardware production. 800 pounds could buy you a very nice Mac or PC. Or to look at it from a different angle, quite a nice little workstation with comparable multimedia and application capability could be cobbled together for not much outlay.
And this raises another problem, the PC platform gives the use access to both a well developed second hand market and the rapid pace of new hardware development. This means that a basic Internet and multimedia workstation can be slapped together from the parts that other people are throwing out. If someone gives you an old Pentium III, you can make it into a machine that might match a state of the art RISCOS work station in some capabilities and even surpass it in others.
In short, there is no ‘low-end’ if you want a reasonably capable RISC OS machine. You might get away with putting 50 pounds a year into an old PC that offers adequate performance for basic tasks but there it just isn’t an equivalent price:performance balance on RISCOS. RISCOS workstations are prestige workstations with a correspondingly prestige price tag.
I’m going to to employ some cynicism for a moment here and make what I think might be a controversial point: I wonder why the two currently operating workstation manufacturers have custom designed their own hardware? The developers of both RISCOS branches have had to remove the legacy hardware support. I can’t see what special RISCOS support is built into a machine like the Iyonix as the graphics are provided by an NVIDIA card attached via a PCI slot and the sound is also provided by a rather standard chip. In the case of the of the A9Home, there might be some justification in the custom hardware as they have abandoned a standard form factor to make the machine uniquely compact. I’ll get further into this point in the final section of the article.
Total Cost of Ownership
Cost Of Software
RISCOS has a fair amount of free software available to it but a lot of the software is commercial or shareware. This means that, in order actually use a RISCOS powered computer, you might have to spend some money on applications. In contrast to this, it’s hard to think of any class of application that isn’t represented within the world of Linux freeware, for example. The quality of these apps ranges between being adequate for basic tasks and applications that meet or even surpass the quality typical of comparable commercial apps.
If a lone programmer works to create a good quality application for RISCOS, he is well within his rights to sell his software and many RISC OS users are willing to reward such an individual or company for their hard work by handing over some cash. This might extend to voluntarily donating to a worthwhile software project. Equipping a RISCOS workstation with a word processor, a vector art package and a few other little utilities might cost well over two hundred pounds. As reasonable and noble as this might be, this cost has to to be added to cost of actually buying into RISCOS in the first place.
There are other, small areas in which being a RISC OS user might cost you a bit more money. Just seen a MP3 player or digital camera on special offer at the supermarket? You can’t buy it unless you’re sure that it works with RISCOS. Situations such as this might seem minor but having to make sure that your add-on peripheral purchases work with RISCOS adds to the cost.
These are the sorts of issues that kept some people away from the Mac platform in the past. The entry level for a workstation was high and the software maintenance cost were similarly high. Small utilities which would be free on other platforms might each require a $10 registration on the Mac. Add to this cost of a couple of shareware drivers and the total cost of ownership implicit in using the platform increased still further. I wonder if this was one was one motivations in Apple’s decision to include a fairly comprehensive software bundle with the OS?
Part 3 – What It Would Take To Drag Me Back Onto The Platform
This section is the most speculative and therefore the most personal part of the article. If RISCOS is so great, why don’t I use it? What would it take to drag me back? Personally, there is no way that I am buying into the current model of buying a very expensive, under-speced proprietary workstation or of paying quite a lot of money for periodic OS updates. Part of the reason is that I don’t have a lot of money but even if I had an much larger income, I doubt that I could be convinced to invest in the platform as it stands at the time of writing. Here are some alternatives that would make me interested again:
Open up the source code:
Efforts in this direction have already begun on the part of Castle Technology’s RISC OS Open project. Check out their FAQ for more info:
At the time writing, RISCOS Open haven’t actually released any source code but they have established a web presence for the project and made efforts to maintain contact with the RO community. Apparently, the planned release is being held back while the final polish is applied to the legal documentation. What follows is my (perhaps flawed) interpretation of the project from of the released facts:
In the documentation on the website, they do not explicitly state that they are planning to release the source code of the entire operating system even though it is implied by their stated goals for the project. They do state that they are planning a phased release of the source, and in that spirit, the first releases will be the source to some of the support applications and utilities.
They are not releasing the source code under an ‘open source’ licence such as the BSD. I for one welcome this move on their part. It’s hard to see how they could hope to make money as a company if they were to simply ‘give away’ their product. The idea seems to be that, if a developer makes an improvement to a RISCOS component, the improved source has to be made public. RISC OS Open will then decide whether or not to move this improvement back into the the source code tree. Presumably, even if they do not, other developers will be able to reuse and build upon this work.
The second important aspect of this licence is that if you want to commercially exploit RISC OS code in this manner, you have to pay some royalties back to Castle. Again, this makes good sense to me.
My hope would be that at some point in the near future, in becomes possible to build a complete version of RISCOS from the sources. This means that the entire operating system could be theoretically ported to other hardware platforms. How much work this would actually entail remains to be seen, but remember, RISCOS 5 (the version that this release is probably going to be based on) is already free of any dependence on legacy, custom hardware. Some of RISCOS is very old but as RISCOS 5 has already been modified to run on currently available ARM chips, nearly every part of it has been at least looked at and recompiled in the last few years.
If this were to happen, it would open up the possibility of either community-based or commercial groups moving the OS to other hardware platforms. ARM powered motherboards, PDAs, set top boxes and even phones are ubiquitous and many of these could, in theory, serve as a platform for running RISCOS. Other groups having access to the source code of RISCOS means that further development of the platform can be focused around software development – in this case, porting the OS – rather than, usually more expensive, hardware development.
A PDA Port Of RISCOS
I feel that one barrier to greater adoption of RISCOS stems from its orienting within the market as a ‘windows-beater’. I have already outlined its failings in this context.
RISCOS would have a lot going for it in a PDA implementation. The OS could be ported to run as the replacement OS for an existing ARM-based PDA. A 64MB 400MHz environment would be luxurious by RISCOS standards particular as it would only be driving a small screen. RISC OS wins here again as it was developed to run in a variety of screen modes and to be viable on relatively low-res screens.
RISC OS could offer a lot as a PDA OS but a PDA port could, in return, offer a lot to RISCOS. Suddenly, an entire class of PDA orientated application becomes viable: mileage calculators, mapping applications, PIM applications, etc. These are a type of application that are useful without a monster processor to back them up. It goes without saying, that any development of this sort feeds back into and benefits the desktop version of RISCOS.
In addition to this, there is suddenly an added justification to using RISCOS versions of various applications. If a browser doesn’t support the latest, all singing, all dancing version of the flash player, this doesn’t really matter in the case of a PDA browser. Speed, integration and consistency are more important in portable computing.
PDA RISC OS opens up further, economic justifications from the perspective of the user. Consider the case of a small shareware utility or a driver that requires a cash registration or implies that a donation is expected: does the user pay up, in order to run the program on his desktop RISCOS workstation or does he instead download the equivalent freeware utility for the PC sitting next to it? However, a small payment to add extra functionality to his PDA doesn’t invoke the same dilemma as a piece of Linux freeware might not be as readily viable on a PDA.
Even more exciting, some PDAs can support an add-on VGA output card, this means that such a PDA could be, with the addition of a USB keyboard and mouse, a complete base unit. This further re-enforces the idea of RISCOS being a desktop and a PDA OS. With such a set-up, the user cannot only carry some of his synchronised data around with him, such a user would also be able to take this to the next level be able to carry around some of his favourite apps with him 🙂
Given freer access, RISCOS could be the OS of the user’s PDA, desktop workstation and even supportable as a host OS via emulation when the user is using his PC. There is already a freeware, portable RISC PC emulator. When the user wants to run his RISC OS apps on the PC, he simply establishes a connection between the PC and the PDA and the PC is able to access contents of the PDA as a disk drive. The user then runs the emulator software, and voila, he can then access both his applications and his data. Seamless. This last point might seem fanciful but actually, as the emulator is freeware and ports exist for Windows and Linux, it can already be achieved.
The possibility of a complete port of the base OS to other hardware platforms opens up other intriguing possibilities such as set top box form factor machines.
And there you have it, some of the thoughts of an ex-RISCOS user.
About the author:
Mike is a guy who is geekier than an 80’s guy holding one of those synthesisers which you wear like a guitar. Come and read about his lack of ever finishing any of his projects on his website – http://www.unmusic.co.uk/.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
I have said before that RISC OS has found itself colliding with modern requirements, causing a lot of comparison with Windows and other operating systems. I believe that this kind of comparision is a detriment to the platform. RISC OS isn’t Windows or Linux or OS X, it shouldn’t try to be those things. Once you start trying to be Windows, you will fall short and feel that things are indaequate.
I don’t think that RISC OS is inadequate. It’s a very nice Operating System, good for emebedded spaces and very low power consumption / cooling. It runs on ARM chips, available in many PDAs. I feel that if RISC OS tries to be Windows, it will die or stay in a perpetual state of inadequancy (Amiga). RISC OS should instead be focusing on doing what it does best, Castle and ROS could be making mintage off of expensive embedded computer contracts in the industrial manufacturing industry.
PS. Good article, the author is honest but humble in his opinion. Windows/Mac/Linux users could learn something here. The author should have linked to the specific RISC OS browsers though, instead of bypassing them for Firefox. For example, this article on Drobe, compares and contrasts the main browsers for RISC OS: http://www.drobe.co.uk/riscos/artifact1297.html
Edited 2006-12-07 12:48
To me the biggest problem with RISC OS as a modern platform is its fragility. The lack of pre-emptive multi-tasking and decent memory protection are big problems. These problems IMHO limit its usefulness as an embedded or PDA OS.
Indeed IMHO RISC OS is probably a worse starting point for a PDA OS than Linux. The GUI is not at all suited to pen-based working, so it would need to be replaced. (PDA pens don’t have buttons, so what do you do for menus?) What that leaves you with that is of use is the kernel, Filer, Font Manager, and Draw Module. Whilst the Font Manager used to kick arse, it’s now looking quite dated, and the Draw Module was always lacking.
What’s sad is that Acorn were developing another OS for the Archimedes. It was called ARX, and was being developed at the Acorn Palo Alto Research Centre. It was to be a modern OS, with memory protection and pre-emptive multi-tasking like Unix, with a GUI similar to Mac OS – the guys working on it were experts in OS design. Unfortunately the project was poorly managed (as most Acorn projects were). Management decided to kill the project because the predicted finish date was long after the launch date for the Archimedes – Arthur was thrown together in a hurry, and the rest is history.
For those that don’t know, Arthur was essentially developed by a bunch of BBC Micro games developers who had little experience in OS design. I believe that none of the folks that had been working on ARX worked on Arthur. It was designed to be compatible (to an extent) with the earlier BBC Micro OS – much of the early software on Archimedes machines was ports of BBC Micro apps. It was never really designed to be a serious OS.
IMHO what Acorn should have done was get in some decent management for the ARX project. Had they done that they’d have ended up with a serious computer system and things may have turned out differently. They could potentially have competed in the spaces that Unix and Mac OS were dominating. Unfortunately Arthur meant they were only suited to the education and hobbyist market.