ROOL Forum: Recent posts

Mon, 09 Feb 2026 21:46:31 +0000

A good place to start is Dave’s IPP web page
I have been using his IPPtrnspt application with my network connected Epson printer for over a year, and it works very well for me.

Mon, 09 Feb 2026 20:33:59 +0000

Dave Higton – I can’t work out how to add my printer, though I have IPP enabled on it – please can you enlighten me?

Mon, 09 Feb 2026 20:32:59 +0000

Thank you for that, David Gee

Mon, 09 Feb 2026 19:06:34 +0000

I get the errir message:

Peer sent fatal TLS alert: Error in protocol version

when I try to open this site using Iris. Is it just me or is this a common experience?

Mon, 09 Feb 2026 19:02:54 +0000

Hi Timo,
Bravo for your work and your tenacity.
I’m going to ask a possibly stupid question.
To make your model work you have to modify a lot the BSD version you are working on.

Can we draw inspiration from what was done for the Wifi TCPIP stack, I think it would be an excellent (working) model.
On the other hand, I don’t know if sources are available even to study them.
The idea is to move in the right direction for the development of Risc OS.

Mon, 09 Feb 2026 19:01:14 +0000

I’m not sure that three individuals — however talented — can accomplish a task that was beyond Apple and IBM.

I wouldn’t be so sure: the task doesn’t compare. The Windows, OS/2 or MacOS APIs were significantly larger than those provided by RISC OS. The number of hardware configurations is also lower for RISC OS.

Mon, 09 Feb 2026 18:53:31 +0000

By paying developers, they will be able to steer the development in the way they think best

Except that’s explicitly been stated what they’re not going to do. They do not wish to offer technical or design goals, and have stated that they wish the team that they hire to do it whatever way they want. That’s a way of doing things, but they’ve explicitly said that they don’t want to bring any plans to the table.

Meanwhile three developers are proposing to produce modern operating systems with some level of compatibility with existing applications.

Not exactly. I’m doing what I can to incrementally update parts of the system to be capable of 64-bit and providing build and debug tooling, documentation, environments and automation to allow myself and others to do that. I’m providing education in the form of presentations and regular live coding to demonstrate that. And I’m engaging with people within the community to provide advice and recommendations to do what they need. As I’ve stated in various discussions, this is not something that can be done alone, and why almost every time these issues arise, I ask for help in doing this. I do not believe that this is a task that individuals can do.

However, having already got a 64-bit version of RISC OS to work against, knowing a good chunk of the system, I’m still trying to do all that I can to try to advance that.

The others are doing this because they enjoy things as well, I believe. They have different targets to myself, but that’s fine.

I’m not sure that three individuals — however talented — can accomplish a task that was beyond Apple and IBM. Linus Torvalds only had to develop a kernel as much of the other work had already been done! The most logical approach, I believe, would be to build a RISC OS-like GUI on top of an existing Unix-based OS together with a way of emulating existing applications. But nobody’s doing this, AFAIK.

Probably because it’d be relatively pointless – only my view, obviously. There’s really no part of RISC OS applications that are comparable to other software developed in the last 20-30 years, or which have sufficient holding power to make such efforts worthwhile. The RISC OS UI has little to offer compared to other systems – most perceived deficiencies are in differences in the way of doing things, which are easily worked around, and there are huge improvements in many areas. If you want to use your old applications on a modern operating system, run an emulator, and you’ve got everything you had before. The RISC OS Look And Feel window manager configuration for Linux was just that – a look and feel with little else.

There are advantages in being able to run RISC OS applications under emulation in a semi-integrated way with the rest of the system, and these can be made work given time. The RISC OS Pyromaniac native wimp interface is slowly being developed to demonstrate parts of that, but even the rudimentary interactions mean that it is possible to launch RISC OS applications from files and work with them right now. That’s just a side-effect of designing a version of RISC OS that is intended to work with the host environment.

Systems like the RISC OS on Linux allows you to work with RISC OS as it is in emulation but with a better integration.

Example of RISC OS Pyromaniac running full screen, on a Mac:

Example of RISC OS Pyromaniac using a trivial integration to launch the OS from the host system to allow it to be edited as usual:

https://share.gerph.org/s/p9kUU2Jzlu4pLlw

And then there are other ways of integrating RISC OS into different working environments… This is the RISC OS inside Jupyter notebooks feasibility work from 5 years ago:

https://share.gerph.org/s/alB9YwcVRHh4MWd

Or running RISC OS within a SSH shell with VNC access:

https://share.gerph.org/s/LdNwqSp5Bxfkms2

Which is basically my way of saying that there are lots of things that could be done, and which you can see the benefits of doing in different ways.

BUT, and it’s a very large BUT, unless there is some work done, nothing will happen to RISC OS itself. This is why the intention (at least from myself) is to move in incremental steps, produce more manageable, more portable components, and expand the ability to make more things work. To take your approach as an example, building a RISC OS-like GUI that can support emulating existing applications could be done many ways – the Linux running of RISC OS as a whole is one example. Running some parts of the system in the host so that the emulated parts are able to see RISC OS as they expect, but appear in a more modern GUI, that’s pretty much what RISC OS Pyromaniac does. If you don’t like that Pyromaniac is slow and in Python, then that’s fine – it’s a demonstration that all this is possible. You just have to do something.

The biggest thing holding RISC OS back (other than the desire of people to change nothing, which is kinda related) is that people only TALK about what should be done. Rather than getting on and doing it. That’s fine as there probably aren’t that many people who can do things. Hey-ho.

Feel free to show some support for those of us that are doing things, though.

Mon, 09 Feb 2026 15:29:12 +0000

I find all of this discussion somewhat strange.

ROOL’s strategy relies on funding. By paying developers, they will be able to steer the development in the way they think best (and, if you look at the wiki, it is clear that they have thought about the issues). Their approach seems to be to rewrite modules in C as and when there is sufficient money. They could then be recompiled to run on 64 bit processors. However, at the present rate of funding this would take not far short of 500 years.

Meanwhile three developers are proposing to produce modern operating systems with some level of compatibility with existing applications. This was a task which defeated both Apple and IBM, both separately and together. Apple in the end built a Mac-like GUI on top of an existing kernel and, essentially, Free BSD. IBM bought Red Hat and adopted RHEL.

Both Apple and Microsoft faced this issue when going 32-bit, so going 64 bit didn’t involve a huge amount of additional effort. Apple’s answer to compatibility was to produce an emulation layer (“Classic Mode”). This was abandoned long ago. The problem with RISC OS is that — unlike the Mac — many key applications are no longer being developed, even where the source code is available (and, in the short time I’ve been using RISC OS, since 2012, ArtWorks, Easi/Tech Writer and Ovation Pro have joined the list, whilst efforts to revive Impression have stalled). So compatibility — even with 26-bit applications — will always be a concern.

Microsoft introduced a 32-bit layer on top of the existing DOS/Windows setup, whilst hiring an experienced OS developer (Dave Cutler) to work on a replacement (and Windows NT et seq have many echoes of VMS).

I’m not sure that three individuals — however talented — can accomplish a task that was beyond Apple and IBM. Linus Torvalds only had to develop a kernel as much of the other work had already been done! The most logical approach, I believe, would be to build a RISC OS-like GUI on top of an existing Unix-based OS together with a way of emulating existing applications. But nobody’s doing this, AFAIK.

Mon, 09 Feb 2026 12:48:34 +0000

Just wondering has there been any updates on Iron Dignity, Magnetoids or any of the raytracing stuff mentioned here. Also possibly new stuff from the Iron Dignity team.

I don’t think anyone could deny having these apps or even new stuff updated for modern systems would be very desirable. I for one would pay decent money for at least updated and complete versions of ID and the raytracing stuff including a full editor.

Hope there has been positive movement in recent years.

Mon, 09 Feb 2026 10:44:44 +0000

You can find a discussion of printing files that arrive in a shared folder on a Mac at:
https://www.emaculation.com/doku.php/sheepshaver_basil…

This is concerned with running an emulator for classic Macs on the same Mac, where there is a shared folder, so it won’t address how items get into the shared folder. There are AppleScript files to download, and descriptions of how to set up folder actions depending on which version of macOS you have.

Sun, 08 Feb 2026 23:56:26 +0000

There’s also a beta v2.25.

2.25 and 2.26 I think