Bristol RISC OS Users Group

I've just got back from an enjoyable evening with a few members of the Bristol RISC OS Users Group at the King William in King St.  A short 2 mins walk from my Bristol flat it was a most convenient location.  It was an evening of talking about everything computing, and lots of interesting opinions about what is good and bad about RISC OS, Windows, Linux, Printers, Nuclear power (!), and much more...

While my work as an IT Director has lead me to use Windows and Microsoft .NET for systems development, it was great to hear some enthusiasm for RISC OS and the simplicity of the Acorn computer.   The pragmatist in me knows that RISC OS is unlikely to get the kind of development it needs to bring it up to date, but we can all dream a bit and think what could or might have been...

Some thoughts....

RISC OS occupies a fairly unique space in that it is a native ARM operating system, and isn't Linux.  It has the potential to attract many developers and enthusiasts from the Open Source community who would like to work on something with a lot more potential for improvement.  Regular sustained publicity is the key to this and nobody would suggest its an easy thing to achieve.

From a development perspective my view is pretty clear on the main thing that is needed for RISC OS.  In my opinion this surpasses all others as it is critical for using modern hardware and porting applications.

The kernel needs a pre-emptive multi-tasking system, allowing a typical mix of processes, threads, synchronisation objects, memory management, and security.  This is the "new world" that is essential for dealing with modern multi-core ARM hardware.  The "old world" would then run in a single thread bound to a single processor core with interfaces to communicate with the "new world".   After initial fixes have been made to the core OS code (SWI handler, interrupt handlers, WIMP task and memory management, etc), each module would be flagged as "new world" when it has been re-written (preferably in a higher level language such as C++) and is thread-safe.  The result is RISC OS initially still running largely from existing code, allowing the subsequent re-engineering process to take place piece by piece.

Writing the multi-tasking Kernel code and APIs is something I could do myself with a bit of technical assistance relating to the latest ARM hardware.  I have a lot of experience in writing multi-threaded code at a Win32 level in C, and in the managed environment of .NET.   However, making the existing RISC OS code work with it would require a major team effort, and unless that team approach is organised properly it just won't get off the ground.

As with everything of this kind, it's a massive job and one that is likely to need more highly skilled developers then we currently have to complete it.  Right now many other people will have other development priorities, may not agree with me (!!), and will flag up all manner of headaches in the workings of the OS that would make this difficult.

Just my thoughts after an interesting evening of discussions.   I'm as outspoken as usual, no doubt.. :-)