HelenOS as a foundation for next generation RISC OS

The notion of building a next generation RISC OS on top of an established operating system is far from new. (Indeed, Acorn were rumoured to be considering such a thing before ceasing development of desktop computers.) Several candidate operating systems have been suggested, with Genode probably being the common suggestion. However another interesting candidate is HelenOS. (This was mentioned in a comment on another post by Paolo Fabio Zaino.)

http://www.helenos.org/

https://en.wikipedia.org/wiki/HelenOS

It’s a microkernel based operating system. The kernel handles the bare-metal stuff, multitasking, multithreading, and intertask communication. Everything else (e.g. filesystems, GUI, device drivers) happens in user space, by running “servers” that other tasks can connect to and communicate with, with synchronization being managed by the kernel. The servers are extremely flexible and modular in nature.

From what I can tell, all the usual horrors of preemptive multitasking are nicely encapsulated within the kernel. Therefore, naive communication with the servers (e.g. requesting that X be done, and then cycling until X has either been done or refused) is a valid (although not necessarily the best) way of doing things, that will neither hog control, nor clash with other tasks if execution gets preempted. It’s probably as good as one can realistically hope to get to the basis for a cooperative-to-preemptive compatibility layer.

It’s currently in a state of active development. The low-level stuff is highly advanced, although there’s little in terms of a software base, and the GUI is primitive. (That said, important underlying systems, such as layer compositing are in place.)

It’s almost as if they need someone to stick a friendly desktop over it, which accommodates a nice ecosystem of zero-install software, and has a substantial fanbase…

@ DavidS

If we are going to look at a MicroKernel, at least go wit a reasonable one, like Exec or one of its many clones.

You obviously know that Exec (the AmigaOS Task Scheduler kernel component) is still copyright of Cloanto and they still have huge copyright battles going on today between Cloanto and Hyperion right?

So, I assume (please correct me if I am wrong) you meant instead of working on an micro-kernel approach, we should write a TaskScheduler from ground up on top of RISC OS existing kernel and that Task Scheduler should be inspired by Exec which expect the lower level Kernel to be re-entrant because Exec was/is pre-emptive and also we should lose MMU support because AmigaOS doesn’t actually support MMU…

Well that’s your proposal, I am listening, just want to make sure I understood you correctly, thanks in advance for any clarification :)

Thanks DavidS, I just didn’t like the sound of your comment, it sounded to me like a try to shut Charlotte’s idea.

Everything is ok and we’re friends :)

The approach has merit, as have many before such as Liam Proven’s RISC OS / BeOS mash-up. The issue as ever is; getting everyone behind it, and resources to do it.

Very nice with ideas for building riscos on microkernel. The reason why I prefers Genode is that Genode base-hw kernel doesn’t do much at all. A great benefit is that you can run several systems at the same time, using a little vm engine. The whole thing probably fails if we stay with assembler. Feel free to join discussion on chatcube. I tried to create a group yesterday, but I think it needs mor than two members to work.

The whole thing probably fails if we stay with assembler.

this, exactly this, thanks for pointing it our Michael :)

So, if the community want/will stick to the ASM Spaghetti architecture, then it will be extremely hard to replace pieces of the existing RISC OS with a micro-kernel (again also Acorn failed to attempt that). It’s not impossible (so please don’t get it as an attempt to stop who wants to purse such a path), but it would be much much easier with a kernel that wouldn’t have the same architecture as the RISC OS kernel.

Genode makes a lot of sense, because it’s extremely small and (as Michael pointed out correctly) does very little which also implies possibly less changes in RISC OS.

A possible approach using HelenOS¹ (for who like such type of things):

HelenOS could be used to virtualize the existing RISC OS and then use the messaging architecture to create intercommunication between the host and the VMs (or even better if emulators). This may allow to run RISC OS apps inside a HelenOS window and create (from the HelenOS side) a way to forward events to RISC OS. For who is old enough a similar approach was taken in OS/2 to run DOS applications.

RISC OS could be transformed into a single task OS (which pretty much it is already) and, instead of having to create a reentrant kernel on RISC OS, one could leverage HelenOS and infrastructures similar to HostFS for the storage.

Virtual NIC drivers for the networking to an application in a VM.

However the downside is that I fear the configuration may get complex, so not so sure it would be something for everyone…

¹ Pure theory at this stage and definitely needs improvements

BTW: ChatCube RISC OS Coding room created, if we don’t like the name we can change it :)

Though this has nothing to
do with the choice of programming languages,
probably do to people quickly adding this or
that without taking the time to preserve any
structure.

Mostly to do with the ROM space and how much stuff had to be put in there (which at the time included also 3 Apps IIRC)

Also the guys who originally wrote it had to be quick because of the failure of ARX project (which was meant to be the OS for the Archimedes). Then, when RISC OS came out, Arthur had already quite few software that RISC OS had to keep run…

Back in the days I loved RISC OS (and Arthur) because they were like Acorn MOS pumped with hormones lol I had the pleasure to play with the Italian version of the BBC Master Compact before my first Archie, so Archie was super cool for me :)

But nowadays things have changed and to make RISC OS cooperate with something like HelenOS then the old Acorn MOS architecture needs some changes.

It is a viable option (virtualise not emulate I think).

Well Virtualization is partially emulation anyway. However if people do not want to port RISC OS to 64bit then emulation has to be. AArch64 Hypervisor on a CPU that only support AArch64 will only run 64Bit VMs.

So something similar to what I was saying for
a may as well do if we have to use AARCH64 in
the future?

So again, yes if you use an ARM chip that still supports AArch32. AArch64 Hypervisor (on a chip that supports AArch32) can run AArch32 VMs. But if you have an AArch64 only chip then you either go Emulation OR you can go binary translation (but binary translation works only for APPs), so if you want to go Binary Translation for an OS you need to use a similar approach as for RPCEmu (when you run it as “the compiler”).

Sounds like a potentially usable concept.
How far allong has whoever is working on this
gotten?

So, if you consider RPCEmu in compiler mode, then “someone” has go some of it working already ;) but in the case of RPCEmu it emulates the full machine and doesn’t do a messaging based integration (for higher level messages), also RISC OS is executed almost untouched on RPCEmu and you can run only a single instance of it (unless newer versions allow more)

I am assuming some team of people is
working on it as it is an acitve topic still,
and that is the one thing that may have been
missing.

I haven’t seen anyone committing to such a project yet, so I don’t know if anyone is working on such a thing. There have been attempts in the past, but (to my knowledge) they all seems to have got into troubles when it was the moment of having to modify RISC OS to be more integrated with the host system… Maybe RISC OS on Linux will finally achieve that :)

Or potentially just a small translation layer
and use the hosts Sockets implementation?
Like what ArmUAE does for networking for
Amiga OS programs?

Sure, and yes ArmUAE does a great job, but again the OS running on top of it is not deeply integrated with the host system (I would say it’s just “loosely integrated”, if you allow the term). So generally the problem is the integration, not the bare emulation. But yes also a socket proxy would do for a single application… unless you want to run WebJames on the RISC OS side ;)

That is where I think it would be likely to
lose a lot of people. I could be wrong.

Agreed, I have the same fear, unless someone manages to make it seamlessly integrated that spinning a new instance of RISC OS is just like opening a new task, I doubt it will be successful with the masses.

Also the other fear I have with these “different degrees of emulation” for the OS is that they may tend to create a perception the OS is just retro computing, so I still would prefer an effort to port it natively to 64bit (but that is just my opinion)

Theory is proven (eg gravity), so I assume
that you meant to say “Pure Hypothosys”?

Good point! So, we have plenty of examples who have proven the Hypothesis, however RISC OS still hasn’t, so technically it’s a theory, but practically (just for RISC OS) is still an hypothesis… you pick which one works best for you ;)

You remove the little that is mirrored from
MOS and you still have a complete OS, even
true if you were starting at Arthur.

:) I wish it was that easy… if you say that then you miss the point of microcomputers…

MOS, AmigaOS, AtariOS, Arthur, RISC OS, ZX Spectrum Monitor etc… have one fundamental thing in common, all microcomputer OS assumes “everything will go well”. That is a profound difference compared to, let’s says, Linux. It’s almost a philosophical difference if you want. These were the 80s and the microcomputers :)

When I look at RISC OS sources I can’t stop thinking how the heck did they manage to get RISC OS as we know it having that profound philosophy inside of it.

Think about it… it’s still very usable nowadays, it runs on modern ARM (thanks to even more clever people than the one who preceded them who were also astonishingly clever), and yet it still has that assumption that “everything will go well” even in the amount of complexity it has reached… If there is such a thing as a Software Cathedral then RISC OS IS that.

Sure, these days we want practical things, we do not want crashes, we want an OS to integrate with everything, we want it secure and we want to abuse it and have it still working no matter what! But RISC OS is not that OS. If every OS were music then RISC OS would be some delicate and complex symphony, where you must stay quiet to enjoy the beauty, where you must pay attention to perceive every movements (movement is a musical term in this case).

Now, that philosophy is what it causing issues for RISC OS as a modern OS. We live in a world now where the approach is Zero Trust, defensive programming, process isolation, even enclaves to protect the OS from user applications… so tell me are you really sure you just need to “remove that little that is mirrored from MOS”? :)

Though have looked at the details of MOS do
to curiosity in RISC OS usage. It seems that
most of what makes Arthur and RISC OS the OS
they are did not have any similarity in the
MOS system. As most of what is good about
RISC OS (and Arthur before it) is all in SWI
calls that did not have an equilivent on MOS.

There might be more done in SWIs than OSByte/OSWord now, but RISC OS has exactly the same philosophy as MOS; there is a only single user on the system doing a single thing at once – a single OS context. Multi tasking is the thinnest veneers sitting on top, its not just that’s its cooperative, but that single OS context requires all applications to ensure that they are not in the middle of a multi-part OS call when they call Wimp_Poll. Things like file handles are shared by all applications, there is no concept of resource protection.

A real OS needs to have separate contexts for each application (and thread), so any OS API can be called without affecting the operation of any other applications (or thread). This is needed to give stability, resource protection, pre-emptive multi-tasking, multi-threading and multi-core support. It’s also impossible to retro fit to existing code without a full re-write.

@ DavidS

Yes it may crash, no harm done.

Only if it’s not your daily driver OS or you don’t do important things on it. Again the microcomputer philosophy, there were computers to learn computing, to play, to do just little and non-mission-critical things.

Though one of these armored goliaths of an OS crashes,
it is pannic (and seems to happen more for them than
for us).

Nahhh this is just a myth. RISC OS, AmigaOS, Atari TOS, MOS, ZX etc… they all crash more than Linux or macOS (or Windows 10). It’s their nature, their philosophy, system crash is not a big deal on a microcomputer.

DavidS I suggest you read careful what David J Ruck wrote in the previous comment.

Currently it is common for many to come to me
when there terminal or workstation computer
crashes. Of these I can say that there are
multiple crashes per day, with the 34 systems
in question. Of these most of the crashes
are with Windows 10 systems, with macOS a
strong second. Sometimes it is a Linux
workstation.

So if a system like Windows 10 is crashing that means you have a problem with a dodgy driver. Drivers still run in kernel mode and can cause BSODs if they are messing Kernel memory (now keep this is mind for the later comments on RISC OS)

macOS (if executed on Apple Hardware) is fairly stable, unless a user it’s pushing memory limits, aka running stuff that is causing a lot of swapping, in which case it’s probably time to look for more memory or to check why such apps are using too much memory. If there are other reasons for system crashing then look for added hardware with dodgy drivers (same reasons as for Windows 10)

Linux kernel panics are mostly (again) caused by dodgy drivers that can taint the kernel. On Linux this problem usually happens because people tend to force drivers for a different kernel or even distro to another in which case such drivers can mess with the kernel API and memory.

Now to RISC OS, if you have read carefully all my previous IT blah blah, you’ve probably noticed that the word driver (and the term dodgy driver) is the main cause of system crash in those OS, let’s now have a look at the possible causes of crash in RISC OS then:

RISC OS can “only” crash for EVERYTHING :)

You everything can crash a RISC OS system, from a BBC BASIC program that is messing with SWIs and/or memory, to an App that is messing with page 0, to even a piece of code that is accessing the File System in a wonky way.

And when such piece of code crashes it may leave allocated stuff within the kernel that later on may cause weird kernel behaviour and even sudden crashes.

Now, before you start arguing with me, please go to https://gitlab.riscosopen.org/explore/ and start to have a look at how the RISC OS kernel actually really work and how it interact with user-space code and again re-read one more time David J Ruck comment.

If in your experience you are having less crashes in RISC OS than let’s say in macOS it simply LUCK, yes just luck. Maybe you cannot buy apps for RISC OS and so you use only very few applications and/or tools etc… On maybe because on RISC OS you do not try to zip a lot of data (try to zip a CD ROM content of let’s say 600MB). On RISC OS you do not run very complex and memory hungry tasks etc…

BTW I am not trying to change your personal opinion, you’re totally entitled to it. I am just trying to provide the readers of this thread another point of view.

There is nothing you say that I would argue with.

My point was “just in case” you would not agree. Just my perception over your comments, that’s all. You seemed to imply RISC OS was somehow more stable than the other OSes. Anyway cool, thx for the clarification :)

It’s possible that the Pyromanic¹ project by Gerph (Justin Fletcher) might provide of the groundwork for a compatibility layer. This runs ARM32 code in an emulator, while handling SWI calls itself. It’s far from a complete reconstruction of RISC OS, but it’s still impressively advanced. For example, it can run the BASIC interpreter, and can render !Draw files.

At the moment it’s primarily intended as the basis for an online development tool called JFPatch-as-a-service. Most of the SWI handling is done with Python and off-the-shelf libraries, which is fine for a devtool, but not for a compatibility layer. That said, merely implementing functionality without using any part of RISC OS is an huge start, and crosses the “where to even f***ing begin” barrier. I imagine a lot of skilled work has gone in decoding the low level workings of OS calls, and merely having a framework to translate them into a high level description of what the surrounding environment needs to do is a formidable achievement.

¹ The website is https://pyromaniac.riscos.online/, and he provides more detail in the second half of a talk at last month’s ROUGOL meeting https://www.youtube.com/watch?v=YBtVgvJNeNQ&t=3370.

RO on Linux

Do you have a link to that? All I can find is emulators (of RISC OS compatible systems) that run on Linux.

Do you have a link to that? All I can find is emulators (of RISC OS compatible systems) that run on Linux.

See the forum topic here.

See the forum topic here.

Thanks

From what I can tell, RISC OS on Linux is still an emulator¹, albeit one with an interface to the host OS that goes substantially beyond the usual window that captures mouse and keyboard input. In particular it still requires RISC OS ROMS, whereas Pyromaniac implements the functionality of said ROMS itself.

¹ This shouldn’t be considered a criticism of RISC OS on Linux itself. I’m just saying it’s not suited to this particular task.

It’s possible that the Pyromanic project by Gerph (Justin Fletcher) might provide of the groundwork for a compatibility layer.

I almost pointed at Pyromaniac as a basis when you first mentioned HelenOS.
There’s probably less work improving the capabilities of Pyro to be a base layer for a new RO than the work to make HelenOS be something that can run any RO app.

This runs ARM32 code in an emulator, while handling SWI calls itself.

I’ve only skim read stuff to date and do recall the mention of Python in a number of places, which although a fast way of producing something that works doesn’t strike me as a fast run environment, if it’s doing that.

It’s far from a complete reconstruction of RISC OS, but it’s still impressively advanced.

You had registered the connection of Gerph and Select I presume.

In particular it still requires RISC OS ROMS

RISC OS Linux is the ROM with a ‘Linux HAL’. The ROM is a Linux program that you run. The RISC OS desktop runs in an SDL2 window. This means in theory everything in the Linux environment is available to RISC OS.

Not on ARM HW. The emulation is for non-ARM

Gerph was (I think) using X86 for his demonstration, but Pyromaniac is based on Unicorn, which also runs on ARM and ARM64.

My first thought looking at the talk on Pyromaniac project was this would be a great way to work on PMT,threading for Risc OS, freed to test ideas without the constant need to restart with access to good debugging tools etc etc need i go on. maybe there is a chance that his font manager could be transplanted in to the OS to give us unicode fonts. Great talk by the way.

maybe there is a chance that his font manager could be transplanted in to the OS to give us unicode fonts. Great talk by the way.

I thought Cloverleaf had Nemo doing that stuff.

My first thought looking at the talk on Pyromaniac project was this would be a great way to work on PMT,threading for Risc OS, freed to test ideas without the constant need to restart with access to good debugging tools etc etc need i go on.

I was thinking it could be a way to implement PMT, by running each Classic RISC OS application in its own Pyromaniac instance, and letting the New RISC OS microkernel handle the multitasking of said instances.

Meanwhile, the functions used by Pyromaniac to implement the SWI calls would be accessible via a new API, and so many applications written in a high level language could be recompiled to run natively.

(Obviously, this would be a somewhat large project.)

The problem with porting Assembler (as opposed to running in a compatibility layer) is that RISC OS applications communicate with the OS via specific CPU registers, and there’d be no easy way of matching this with how the new API does things. (And that’s assuming that the ISA remained the same.)