Was 2015 the end of RISC OS?

would require every user of COR objects to provide a root scanning interface.

Why? Applications and modules would get their objects from an object manager. The object manager ensures that the memory assigned to an object has all the headers that the memory manager needs (for garbage collection, enlarging buffers, rehashing etc). All that stuff should be hidden from the applications and modules, which are merely clients, between the user and the OS.

Garbage collection needs to have sight of every pointer that is still in use. Once an object has been ‘returned’ to the application it is not possible to infer whether that object is still in use without scanning the application’s pointers… in all its structures… and its stack.

The only other way is for each user to be given an auto-extending array, for example, into which all such objects are put, so that the garbage collector can scan those object trees without needing the user to do its root scanning. However, that would then require the user to remove objects from that array when it no longer needed them – which is just a complicated way of doing explicit freeing.

It is safe to deliver objects over a callback interface, since the object’s lifetime can be limited to only the duration of the callback – the recipient must make a deep copy of anything they need beyond that. However, RO’s API is mostly pull, not push, so objects would need to be persistent.

There are other models, but they get less and less efficient.

The most sane thing I can say is: RISC OS is the best OS I have ever used when it comes to user experience from the OS itself and its many high quality applications. I just demoed it for a friend and started TechWriter in less than a second. Now THAT is impossible on many other systems.

It is right that RISC OS lacks a lot things people expects today, but at what price do we want to dominate the world?
I rather keep things as they are , nice clean and fast. I don’t care if there are milions of RISC OS users , as long as the ecosystem works.

And 2015 , no nothing bad with that year :)

However, that would then require the user to remove objects from that array when it no longer needed them – which is just a complicated way of doing explicit freeing.

This is the crux which forces a distinction between transient and permanent clients of the memory manager. Permanent clients have to remove objects when they are no longer needed, naturally. All computers are finite state machines; operating systems (and programming languages) have the job of maintaining the illusion that they are not. Ever looked at linear logic? It is particularly relevant for operating systems, as it expresses algorithms that conserve resources.

I’m assuming, perhaps unfairly, that you’re familiar with the operation of a mark-and-sweep garbage collector starting from a number of fixed roots. In which case my observation regarding application root scanning is a natural result.

Permanent clients have to remove objects when they are no longer needed, naturally.

And that is not how garbage collection works, no. The point of garbage collection is to free objects automatically without the client notifying anyone that it has finished with the object – that fact is inferred. And that is what requires the root scanning.

Now it can be done without explicit root scanning, but it’s much less efficient and slightly fragile (for example if a client chose to store object pointers shifted right by two bits, or as an offset from some other pointer, or in the RMA or a DA – those references could not be found passively). And since I was talking about objects shared between multiple Wimp tasks, garbage collection would necessarily become less efficient (because all objects that were in use by other tasks would have to be assumed to still be in use while garbage collection occurred for this task).

Explicit freeing, even with the usage count that complex objects require, is not garbage collection.

I rather keep things as they are , nice clean and fast.

Having no capable browser is NOT nice, clean and fast. Same for easy access to multiple CPU cores. Same for WLAN. Same for IPv6. Same for preemptive multitasking. Same for OS-level threading. Same for memory protection. Same for you-name-it.

On the other hand, there is cool application software on RISC OS. Because the WIMP is so well-thought-out. Not because the OS is nice, clean and fast.

Not because the OS is nice, clean and fast.

And you are familiar with the sourcecode? Much better written than most ARM kernels out there.

And you are familiar with the sourcecode? Much better written than most ARM kernels out there.

I don’t know the whole source in detail of course (does anyone). But I know a lot of the APIs and specific modules quite well. There are well-written parts and there are horrific parts. There are clean parts and dirty parts. There are fast parts and slow parts.

Look at our latest discussion wrt a small change in FileSwitch that broke SparkFS. The API to implement an FS based on FileSwitch is one of the less well-designed parts. The whole filing system stack is badly thought out. Much of the driver model of RISC OS is not well-abstracted. The HAL is not really well-abstracted, more the minimum amount of abstraction needed to put it on different platforms. Same for the graphics stuff.

Or look at the FontManager. The printing subsystem. Or the “kernel” which does not even have a proper concept of a process, whetre significant parts of the multitasking is provided by the WindowManager. Omg.

Overall, I don’t think RISC OS is anything like broken beyond repair and therefore needs to be rewritten from the ground up. I think that most parts are changeable to something better while retaining backwards compatibility and make abstraction better. Some things could be replaced completely with something nice, clean and fast. Iterative improvement is possible and should be done (and is IMHO done all the time by people like Jeffrey who actually develop something sintead of people like me who only talk all the time).

The HAL is not really well-abstracted, more the minimum amount of abstraction needed to put it on different platforms. Same for the graphics stuff.

More lowlevel things should be in HAL and it should provide a well defined api that higher level drivers could use. The mechanism is already there.

Explicit freeing, even with the usage count that complex objects require, is not garbage collection.

Certainly not. There are lots of kinds of garbage collection and I was thinking more along the lines of an incremental generational garbage collector, with no sharing, with clients able to set various parameters separately (e.g. step-ratio). You will always need emergency gc to sweep up stuff left by weak references, and you always need those for cyclic dependencies. But the point is to have these variations on a per-client basis. Different jobs need different settings.

It is right that RISC OS lacks a lot things people expects today, but at what price do we want to dominate the world?

I think RISC OS is still a great OS to use today. It’s seen more development during the past 10 years than at anytime under Acorn I reckon. I agree there is a long list of things to be fixed and improved but it is happening. USB, Networking, Filesystems, Graphics and UTF8 support.

The stability of RISC OS has never been so good as it is today and the number of RISC OS platforms available has never been better.
I enjoy using RISC OS on my Rpi3 even more than under emulation, which I’m not sure is a placebo effect or if it actually is better. Regardless, I enjoy using it and seeing it improve every year.

I feel that doing that would quickly lead people to the “why bother” camp and then they’d just run RPCEmu on top of some kind of Linux.

I suppose, but emulation is slow.

Define “OS”. Is the kernel the OS? Is the ROM image the OS? Is the ROM + disc image the OS?

I’m predominantly thinking kernel and drivers and necessary userspace. Adding feature like GPT support, switch to preemptive multitasking, a modern networking stack. Ideally you want to port a lot of the current utilities where possible. Although you would need a RO5 API, you could add POSIX api too to speed up porting, but I’m not a fan of this as it would encourage lazy porting that would break the user experience RO5 aims for, compared to other systems.

Most of the work would be creating the kernel, the rest would be porting and tweaking things from other sources, hopefully without any GPL code.

Although I do know OS design, I am only a user on RO5, and know very little about it’s underlying architecture, and although I know a few assembly languages, ARM isn’t one of them. I am not your man. It’s just an idea I’ve toyed with for a while. I don’t have your history with the OS so I’m not very motivated to fill in the gaps, if I’m honest, but I do like RO and I do want it to live on in some form or another.

I do hope that RISC OS will survive for a long time to come. Something I’d like to see is a decreased reliance on stuff written in assembly language, so that future processor changes won’t be as troublesome.

Something I’d like to see is a decreased reliance on stuff written in assembly language, so that future processor changes won’t be as troublesome.

Doesn’t the castle license forbid porting to non-ARM architectures?

Doesn’t the castle license forbid porting to non-ARM architectures?

I don’t know, but even ARM architecture can cause headaches with processor changes. Granted if everything was written in a portable language it would be hard to stop anyone building RISCOS on a non-ARM architecture, but it doesn’t (necessarily) imply that it’s going to happen. But only by breaking the licence conditions.

Base Licence says:

The phrase “Derivative Work” means any derivative work which is based on, or derived from, RISC OS or any part of RISC OS (whether by modification or translation) and any work subsequently derived from such Derivative Work or any part of it PROVIDED THAT such work is only intended to be used in conjunction with an embodiment (whether physical or emulated) of one or more versions of the ARM processor architecture.

So it’s perfectly okay to write in a portable language as long as you don’t intend to use it on anything but an ARM processor, and writing in a portable language would make it far easier to use it on other ARM processors (or even emulated ARM processors).

Having no capable browser is NOT nice, clean and fast.

That all depends. I find I can get work done under RISC OS because the simplicity of the browser helps me concentrate. I don’t get sidetracked into watching a zombie movie because, well, because what? Because it’s less effort than coding? ;-)

Or look at the FontManager.

It’s not bad for an anglocentric technology from the late ‘80s that’s had “extended characters” bolted on. It’s not bad for what it started out as, but it’s not good compared to today’s systems.

The printing subsystem.

It’s slow, it’s clunky, and I’d probably wet myself if I looked at how it actually does what it does; but unlike Windows that took several tries before GDI actually managed to have “on screen” and “on paper” resemble each other, RISC OS was there right from the start. DTP on RISC OS has never been particularly painful. Thankfully.

To be honest, I wouldn’t touch the printing system just yet. It would be far more useful to have an “AirPrint” driver so the machine is capable of talking to the new batch of printers (the base no-frills level appears to be a sort-of-RLE bitmap called UDF). Our problem is an inability to talk to printers.

Oh, yeah, and the PS driver is crap, but since PS3 is a commercial product, I don’t see there being much desire to fix PS2 even though it’s yet another thing that cocks up when confronted with Unicode.

Or the “kernel” which does not even have a proper concept of a process, whetre significant parts of the multitasking is provided by the WindowManager. Omg.

That’s as it has always been. The kernel is single user single state and has been that way since Arthur. The Wimp (as of RISC OS 2) is the smoke and mirrors that provides the illusion of multitasking. The only real change in this was to move the memory mapping into the kernel (AMB), perhaps so the kernel and the Wimp can both have the same view of memory. Or maybe because lazy swapping uses an abort handler and it’s just simpler to have the lower level code deal with that?
That’s not to say your OMG isn’t justified, just saying it’s been like that for thirty odd years…

I enjoy using RISC OS on my Rpi3 even more than under emulation, which I’m not sure is a placebo effect or if it actually is better.

Real hardware is better. As far as I’m aware, the most recent emulation is an emulation of a quarter century old machine with a twenty year old processor. Emulation might run pretty fast (depends upon your machine) but it’s no comparison to a quad core ARMv7 or ARMv8 with VFP, Neon, etc; that doesn’t lose its marbles if you ask it to deal with FHD in 16M colours. ;-)

you could add POSIX api too to speed up porting

Isn’t that what GCCSDK tries to do, within the obvious limitations of the differences between the systems?

hopefully without any GPL code.

Hopefully? Absolutely. RISC OS is a GPL free zone. I’ve written at length why GPL sucks, I’m sure a quick search might find some of it if you’re interested…

Doesn’t the castle license forbid porting to non-ARM architectures?

I think what he meant was “more stuff written in C so it can be recompiled for newer architectures” (like Linux). Problem is, we’d need to have the compiler to be aware before the OS can be ported to this new setup. Norcroft isn’t bad, but it’s worth keeping in mind that we are still stuck emulating a dead and long gone floating point unit on machines with massively faster hardware floating point inside (everything post Iyonix has had some form of VFP). If RISC OS and it’s tool chain can’t manage to support hardware FP in the same decade, what hope a “simple recompile” for this strange new architecture we’re talking about?

but emulation is slow

Certainly slower that the Titanium or RPi3B+ but RPCEmu processor benchmarks here are a bit faster that those from RPi1. RPCEmu hostfs disc speeds are well in front of the Titanium’s ADFS. This from RPCEmu on Ubuntu 18.04 on a VM on an iMac. The Mac VRPC is (was) a good performer too but that is only 32bit which the Mac will reject next year.

So slower certainly but not too slow I find. RPCEmu 0.9.0 is looking rather pleasing here.

Adding feature like GPT support, switch to preemptive multitasking, a modern networking stack.

There are no limitations inside the current RISC OS source code that would prevent this. GPT support is planned. A more modern network stack (based on BSD work) is planned too. Preemptive multitasking and WiFi were present before… and so could be done again.

You’re just asking for things that’ll be present in RISC OS. See there:
https://www.riscosopen.org/bounty/polls/10 (GPT support)
https://www.riscosopen.org/bounty/polls/29 (FreeBSD based network stack)
http://www.nedprod.com/programs/RISC-OS/Wimp2/index.html (latest attempt at preemptive multitasking)

For 26bit support, we have the best emulation layers (Aemulor & ADFFS) and the best emulators (ArchiEmu and Arcem) on the market. To make them again would need years of work.

There are no limitations inside the current RISC OS source code that would prevent this.

I know, but a cleaner codebase can make things faster and simpler to develop. Why do you think Redhat switched for xorg to wayland.

WiFi were present before

Really? o.0

https://www.riscosopen.org/bounty/polls/29 (FreeBSD based network stack)

but why backport it to RO3.5+?

http://www.nedprod.com/programs/RISC-OS/Wimp2/index.html (latest attempt at preemptive multitasking)

That’s interesting, but I’m not a fan of WIMP managing the multitasking.

or 26bit support, we have the best emulation layers (Aemulor & ADFFS) and the best emulators (ArchiEmu and Arcem) on the market. To make them again would need years of work.

If the job is done right, they wont need rewriting.

There are no limitations inside the current RISC OS source code that would prevent this.

I know, but a cleaner codebase can make things faster and simpler to develop. Why do you think Redhat switched for xorg to wayland.

Possibly because other people had already done the hard work of creating it? :-) Development started in 2008, first release in 2012, and only in 2018 are RedHat offering it as a “tech preview”.

https://www.riscosopen.org/bounty/polls/29 (FreeBSD based network stack)

but why backport it to RO3.5+?

Probably because “why not”. Apart from threads (which even RISC OS 5 doesn’t properly support yet), there aren’t any major features which RISC OS 5 has but 3.5 lacks. So well-written code (especially if 99% of it is C) should only need a few concessions to be able to run on 3.5.

Of course, if useful threads arrive before the network stack arrives, then maybe the goalposts will move a bit in order to allow a thread-enabled (and therefore RISC OS 5-only) network stack to be produced more quickly, and the 3.5-compatibility will be put on the backburner.

Rick claimed

DTP on RISC OS has never been particularly painful. Thankfully.

I am banging my head on the desk in a particularly loud and theatrical way.

When Acorn first started selling “DTP” systems they had a dedicated sales guy for it – Simon somebody, I forget. He tried flogging some kit to me so I asked him “so, how do you deal with dot gain calibration?”

“What’s dot gain?” he said.

“Never particularly painful” he says? As I’m the guy who wrote the only dot-gain correction and monitor calibration system RO ever had, AND hacked the PostScript printer driver to support masked deep sprites and CMYK, I can confirm that yes, it was particularly painful and always has been.

Steffen said

Fontmanager [and] Printing

Yes. Precisely.

Real hardware is better.

By what metric? Do you mean faster? Why can’t I write processor-intensive stuff in OpenCL and have that executed outside the emulator super-fast? Because RO doesn’t support OpenCL at all. This emulator is running at close to 1GHz. That’ll do me, I can’t type faster than that.

I’m not a fan of WIMP managing the multitasking

I’ve said many times that the task switching should all be in TaskManager (with threading), the UI in WindowManager and the rendering of the UI somewhere else, Desktop probably. That would allow interesting things to be done more easily, but that’s just a change to three modules, not a brand new codebase.

I know, but a cleaner codebase can make things faster and simpler to develop. Why do you think Redhat switched for xorg to wayland.

Yep, so the idea – after all – is not to start again from a new codebase, but to switch to something already existing.

Anyway, I don’t think it’ll speed up things. On one hand you’ll get some modern features. On the other, you’ll have to recreate all the API/ABI of RISC OS 32bit. That’s the riscose project. http://riscose.sourceforge.net/

If the job is done right, they wont need rewriting.

I’m not sure to understand.

If you talk about portability, I suspect that only Arcem would work under a riscose like OS. The 3 others are too closed to the RISC OS core and kernel.

If you talk about a “way to make legacy applications working without a kind of emulation layer”, let’s be clear: it’s impossible, due to processor issues.

For 26bit support, ADFFS & Aemulor are the way to go. And they will need an almost complete rewrite to work on another kernel.

Nota:

Personally, I think we need to code an OS from scratch, and implement necessary 32-bit ABI/API to support legacy RO apps

That’s what ReactOS tries to do with Windows. With much much more people targeted, much more active developers, and a very big codebase already done (Wine). A 20 years old project, still no 1.0 version.

I’m not sure to wait for 20 years to get the equivalent of Arthur.
:)