RISC OS camps to discuss future development | RISC OS news and information from Drobe


Beta! \| About us \| Contact \| Submit news \| RSS \| Twitter	Webspace \| Tech docs \| Downloads \| BBC Micro \| Gallery \| Wallpaper

RISC OS camps to discuss future development

By Chris Williams. Published: 27th Nov 2007, 19:15:50.

Cynical, us?

The two opposing corners of RISC OS have apparently agreed to join forces and jointly coordinate development of the OS. RISCOS Ltd, who produce RISC OS 4 and 6, and RISC OS Open, who are overseeing RISC OS 5 development, promised this week to, effectively, chat to each other over a coffee.

History
Currently the source code to RISC OS is split between two competing camps. ROL are concentrating on building up RISC OS 6 using the source they licensed many moons ago during the break-up of Acorn in 1998. Meanwhile, ROOL are working from the RISC OS 5 source code, which was later handed over to Castle from Pace, another Acorn licencee. Castle used their derivative OS for the XScale-powered Iyonix while ROL produced RISC OS 4 and 6 for RiscPC-class machines and the ARM9-powered A9home. It sounds complex because it is.

Incompatibilities have edged their way into the OS as the two separate teams worked away on the source. There are features present in RISC OS 4 and 6 that are not in 5, and vice-versa. Third party programmers have been forced to use features common to both strands and punters have been unable to decide which version to stump up their hard earned cash for - a conflict that has gone on for years.

Promises
However RISCOS Ltd and RISC OS Open pledged today to work together to make sure future developments are jointly coordinated: new features added to one stream should be expected to be compatible with features present in another stream. Programming interfaces are therefore expected to be publicly documented to achieve this.

But no specifics have been revealed as a result of today's announcement, described by one senior application developer as being "entirely content-free".It is still unclear how, say programmers speaking to drobe.co.uk, the following will be resolved: the differences between the graphics abstraction and acceleration interfaces in the two OSes, the RISC OS 5 HAL, RISC OS 4 and 6's ImageFileRender system and the way in which each OS version loads executables.

Nor were there any concrete proposals on how ROL and ROOL will migrate features between the two streams, thus synchronising the feature sets with each other and actually ending the development split.

In the meantime, third party coders continue to spend their hard-pressed free time adding RISC OS Select-only features to RISC OS 5 applications via the shared source scheme. ROL and ROOL also want to help software developers to get their heads around conflicting version numbers and other stumbling blocks presented by the split.

In a joint announcement with ROL boss Paul Middleton, ROOL chief Steve Revill gasped: "RISC OS Open and RISCOS Ltd are committed to ensuring that RISC OS users and developers will see real benefits from this co-operation over the coming months and into the years ahead."

Reaction
Punters and ROL fan-boys across Interweb message boards today applauded the decision. However Chris Evans of dealer CJE Micros, which sells the RISC OS 4-powered A9home, said this announcement will not mean the two OS versions will be merged.

He said: "This is great and significant news. I would urge though some caution as I suspect it may be easy to jump to a wrong conclusion about this and think that the two stands of the OS will now merge into one."

It is understood RISC OS 5 and 6 have now diverged internally beyond the point where they can be sensibly merged.

Chris added: "I recall Peter Bonder of Acorn telling me around the time of Black Thursday that Acorn had decided it was to much work to reunify the set-top box strand and desktop strand of RISC OS.

"If with the much larger resources they had and with I suspect less divergence to deal with, I think you will see why I make the statement about today's position."

This is not the first time the market has been promised cooperation between warring factions. In 2004, we were told the Castle and ROL camps had kissed and made up - an agreement that fell apart within weeks. ROL have also repeatedly called upon Castle to cooperate with them to produce a port of RISC OS Select to the Iyonix hardware platform. Each corner of the platform has criticised and disparaged the other's development strategies and both camps have coveted their own approaches to moving RISC OS forward.

As always, only time will prove whether or not today's joint announcement holds any weight whatsoever.

• As an interesting aside, the announcement also notes that the two streams were developed for different markets: roughly speaking, RISC OS 5 for the Iyonix and consumer electronics and RISC OS 4 and 6 for traditional desktop users. It confirmed that while RISC OS 5 is gradually being made available under a shared source licence, third party developers have been able to request access to the RISC OS 4 and 6 code provided a confidentially agreement is signed.

Links
Today's joint announcement
RISCOS Ltd and RISC OS Open

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

At last!!!

markee174 on 27/11/07 7:32PM [ Reply | Permalink | Report ]

Good!

hzn on 27/11/07 7:52PM [ Reply | Permalink | Report ]

Its a small step- but one in the right direction.

Col1 on 27/11/07 8:20PM [ Reply | Permalink | Report ]

Thank God for Drobe. There's been some breathless reaction to this on Usenet, as well as some snipes at this site for not reporting it instantly without pause for breath. But Chris's analysis is, as ever, spot-on. This is a hopeful sign, but there have been similar pronouncements in the past. I wish both ROL and ROOL well with their cooperative efforts, but the true proof of genuine joint working will be concrete resolution of some of the real issues thrown up by the OS fork. Let's see.

In addition, I suspect that the more pressing problem for both versions of the OS is lack of developer time. More cooperation between the two OS development teams may help in some respects, but it won't cure that.

lym on 27/11/07 10:14PM [ Reply | Permalink | Report ]

I'm sceptical - I don't see much in the way of ROOL and ROL agreeing to share source code, only to work towards having similar APIs. Doesn't this basically amount to a gentleman's agreement that ROL won't get p***ed if ROOL rip off their ImageFileRender APIs and similar? If so, all this means is that ROL won't get p***ed - and does anybody notice when they do?

rjek on 27/11/07 10:17PM [ Reply | Permalink | Report ]

In reply to rjek:

Perhaps now RISC OS Ltd are no longer dealing direct with Castle(it would appear this has been the stumbling block in the past), co-operation between the two OS developers may now take place. Ever if the end result is not as many of us would like. Surely simply ensuring API's are compatible is a good thing for all?

sa110 on 27/11/07 10:23PM [ Reply | Permalink | Report ]

Well, I guess that they could also swap source, for example ROL's IFR system for ROOL's Unicode enhancements. Or ROL might contribute sources to ROOL and get substantial price reductions for commercial licences of ROOL's code.

I think ROL's business model consists mostly of selling a finished and polished OS distribution to end users. They could still do that while using the ROOL sources and combining the compiled binaries with high-quality desktop themes, easy installation, support, third-party software bundles, etc.

JGZimmerle on 28/11/07 7:44AM [ Reply | Permalink | Report ]

sa110: yes, sharing the APIs where they have not already incompatibly diverged is a good thing. sa110 and JGZ: But I see nothing in this that suggests anything more than that.

rjek on 28/11/07 8:08AM [ Reply | Permalink | Report ]

"punters have been unable to decide which version to stump up their hard earned cash for"

No, Punters have never been given the opportunity to decide as the two OS branches have never run on the same hardware. ROL have not made Select work on the Iyonix, and RO5 doesn't run on anything RO4/6 runs on - currently, although the ROOL work will (and has already) result in certain components being made available for all machines.

But even taking the announcement just at face value, this is a welcome move to prevent APIs diverging and hopefully stopping the module version wars, which makes life very hard for developers and provides a poor and confusing experience for users.

druck on 28/11/07 8:59AM [ Reply | Permalink | Report ]

As a really small-time developer, anything that helps to clear the general haze of writing software for all our flavours of RISC OS can only be a good thing.

Having kind of returned to RISC OS, I'm rather frustrated at the lack of hard knowledge on converting games to 32-bit neutrality. I've had to rely on one-to-one contact, and hidden pieces of software to achieve some of my aims, and I still have a long way to go. If this venture helps in this respect, I'm all for it. Good luck to them.

sascott on 28/11/07 9:03AM [ Reply | Permalink | Report ]

Convergent APIs sound a good idea but I can't see how it can happen. ROOL are not developing RO5 they are just supplying a repository for an 'Official' version of RO5. Any extra features added to Select, for example, are a divergence in the RISC OS API and would require people to volunteer to match the changes to Select in RO5. It isn't going to happen because volunteer programmers offer what they want to RO5 not what ROOL directs them to add. Similarly ROL are not going to match changes made to RO5 as they may want to use their limited resources to do something else - there's no point in them just tracking RO5.

Even if everything goes perfectly and RO5 and Select have the same API - effectively joining the split - what then? You have a free OS which does the same as Select - where does that leave Select?

I'd like to see ROL and Castle agree to a new Shared source licence acceptable to ROL (I'd give ROL the same rights as Castle) and for all Select's and ROOL's source code to be released under the same licence. I think this is the quickest way to converge the APIs.

coling on 28/11/07 2:26PM [ Reply | Permalink | Report ]

coling: I see no reason why the RO5 Castle Commercial Licence would be in any way not acceptable to ROL. There are a lot of reasons why ROL does not want to take advantage of this licence - the RO5 code base has sufficiently diverged from the ROL one that "porting" all of Select to RO5 is difficult and time consuming, effectively duplicating effort for not much gain (from the ROL viewpoint).

hubersn on 28/11/07 4:02PM [ Reply | Permalink | Report ]

Personally, I think the only way to effectively get rid of this split is either RO5 to be made available for everything that is a minimum A7000/RPC specification up to VRPC's and A9homes, or RO6 to be made available on the Iyonix. As neither options are likely to happen soon, I guess anything else is is simply managing the status quo.

sa110 on 28/11/07 5:39PM [ Reply | Permalink | Report ]

Coling:

According to the announcement is that the two "camps" have agreed to ensure API *compatibility* between the two versions of RISC OS, which is a far cry from agreeing to match one another feature for feature.

What I believe this means (for a very simple example) is that if in one strand someone adds a new function to OS_ArbitrarySWI and uses previously unused reason code 666, then rather than the other strand having that same function added (which, as you rightly say, can't be guaranteed to happen) what will actually happen is that reason code will be, effectively, "reserved" (for want of a better word) for that same function - should someone be willing/able to add it in future - and won't be used for something else in the other strand.

So, as a developer, you can be sure that calling OS_ArbitrarySWI with r0=666, you will either cause Damian to appear, or nothing will happen at all. It won't, in the alternative strand, cause an unexpected pizza delivery.

VinceH on 28/11/07 8:54PM [ Reply | Permalink | Report ]

VinceH:

I'm confused. Why wouldn't we want pizza delivered? Sounds good to me!

Stewy on 28/11/07 10:34PM [ Reply | Permalink | Report ]

In reply to Stewy:

But only if you can specify the toppings!

sa110 on 29/11/07 8:04AM [ Reply | Permalink | Report ]

VinceH: At its basic form, its even simpler than that, if one variant uses OS_ArbitrarySWI 666, the other variant wont use the same 666 for a different purpose. The same with multi function SWI reason codes, error numbers, wimp messages, etc. We probably will end up with two ways of doing the same thing (like with USB), but its far better to have two totally disjoint APIs than have confusing overlap.

druck on 29/11/07 8:53AM [ Reply | Permalink | Report ]

So what's the most popular pizza topping to be randomly selected by VinceH's unexpected pizza delivery?

sa110 on 29/11/07 8:57AM [ Reply | Permalink | Report ]

We will still have to see what happens with the existing API incompatibilities. Networking error codes, various WIMP extensions as well as the stuff mentioned above lead developers to cater for both or ignore both. There is also no mention of time scale.

To put my rose tinted spectacles on for a moment, I'll bet that both parties aren't 100% sure themselves how this is going to be done nor how long it will take and how many incompatibilities can be removed before the price/time/benefit ratio becomes too expensive for the small gain it will give.

However an effort like this is appreciated. Anything that aids developers for the platform is bound to be a benefit.

philipnet on 29/11/07 9:16AM [ Reply | Permalink | Report ]

If the APIs are different, isn't it possible to make a conversion module?

eg. an image file render module that uses changefsi, intergif, spr2png or whatever to provide the same function as select. (But presumably it would be slower.)

jess on 29/11/07 9:34AM [ Reply | Permalink | Report ]

jess: It's not as simple as that: in many cases where using IFR is perfectly valid and safe, it would be entirely unsafe to call out to command-line tools to handle it.

Plus, it would most likely be easier to just rewrite the decoders anyway: there are libraries out there that do most of the work for you already.

rjek on 29/11/07 10:39AM [ Reply | Permalink | Report ]

Where the networking stack returns a different range of error numbers based on what OS version you are running under, which range should be returned? Where the same reason code to a SWI results in different actions, which action prevails? For ImageFileRenderer, do you think it's best to rework the internals or port the low level sprite changes? I bet ROL and ROOL haven't come to a collective decision about all of that.

philipnet on 29/11/07 10:44AM [ Reply | Permalink | Report ]

Druck:

"At its basic form, its even simpler than that, if one variant uses OS_ArbitrarySWI 666, the other variant wont use the same 666 for a different purpose."

That's just about exactly the point I was making, and how I interpreted the announcement.

VinceH on 29/11/07 11:43AM [ Reply | Permalink | Report ]

philipnet:

"I bet ROL and ROOL haven't come to a collective decision about all of that."

I suspect you are right, and the announcement reflects what's been done so far - that they've come to an agreement. There are, I imagine, still many things to work out. Ensuring no future API incompatibilities should be a piece of cake; just implement a formal procedure for API "allocations" which could possibly be based on (or an extension to) the present resource allocation system; it depends on how it's handled internally, which I don't know, and precisely what needs to be covered and how detailed it needs to be. I guess that if it was just the two parties things would be relatively simple, but with the shared-source initiative and the fact that means any of us can contribute, it complicate things a touch.

For differences that have already been committed to Userland things will be more difficult to resolve.

VinceH on 29/11/07 11:56AM [ Reply | Permalink | Report ]

Druck you're wrong. I had cash to spend on upgrading my RiscPC and I wanted new hardware. However since there were two OS's on two hardware choices this meant the choice was OS+Hardware, the two are linked. So I was one of those "punters (that) have been unable to decide which version to stump up their hard earned cash for".

As it turns out I purchased a laptop, installed Linux and re-configured it to look and feel like RISCOS. So both camps have lost out. A damn sight cheaper as well I might add for a machine far faster than the fastest RISCOS box and all the free software you could want.....

I also noticed that RO5 and RO6 have "diverged internally beyond the point where they can be sensibly merged". In other words you will still have a choice of OS(+hardware) unless one camp decides to halt development. Any merging of functionality will help application writers but does absolutely nothing for those wondering which OS+Hardware is the one with a future. The market is too small to support both, one branch will fold. It's just a matter of time.

It's good that they are talking but the end point MUST be one OS that runs on all present hardware. How you get there is up for discussion but dismissing the only logical end point before you start is madness.

mripley on 29/11/07 12:12PM [ Reply | Permalink | Report ]

rjek: but the principle of using other apis is sound? (rather than cli tools)

eg in the image file render situation, a module that calls the internel sprite routines. (This assumes IFR is a new API rather than an enhanced version of an existing one.)

jess on 29/11/07 3:06PM [ Reply | Permalink | Report ]

Jess: Remember that ROL's fork includes many many enhancements to existing APIs as well as new APIs. They're less easy to emulate. (Alpha-channel sprites, for example.)

rjek on 29/11/07 3:17PM [ Reply | Permalink | Report ]

rjek: They wouldn't need to do everything that select can in every case to be a big benefit, would they?

In the IFR example, if there were a dummyIFR module that made a non-select machine appear the same as a select machine, but hardwired to non alpha sprites, that would still be of benefit.

If a reasonable number of programs started using it, ROL could sell the system to Iyonix users. (Or someone else would duplicate it if they didn't)

jess on 29/11/07 3:36PM [ Reply | Permalink | Report ]

I've commented along this before, but it still still seems like an obvious and relatively easy thing, to me.

I've yet to see a point-by-point feature comparison between the two editions of ROS.

This strikes me as an ideal starting point for an effort to bring them up to some kind of parity. It could also be a cooperative project - do it on Wikipedia, for instance.

Starting with the highest common baseline, whatever that is. RO5 didn't start from RO4, did it? That was finished and put on the market by ROLtd. So what is the last common ancestor? RO3.7? Some unreleased Acorn test version of RO4?

Identify that, and then start compiling a list of the new features, in 3 columns: - features shared by RO5 and ROL's Select/Adjust/RO6 - enhancements only in RO5 - enhancements only in S/A/6

Initially, it doesn't need to be a super-detailed programmmers' reference, just a guide for users.

I have seen dozens of beginners' guides to RO, which seem rather pointless to me in 2007 when there can be few newcomers to RO. Let's see a guide to the new stuff for people who last used RO3. Given 2 of these - a guide to the new stuff in RO5, and a guide to the new stuff in ROL's versions, then a comparison shouldn't be hard, should it?

lproven on 30/11/07 12:15PM [ Reply | Permalink | Report ]

There have been point by point feature comparisons on both ROLs and Castles websites. The common ancestor of both RO4 and RO5 was Acorn's RO3.8. Many of the changes that ROL put in to RO4 were also mirrored in RO5 before its release.

druck on 30/11/07 1:11PM [ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Create a new account
Forgot your password?

Search this website

This week's poll

Recent developments have left me feeling...

Assured ROS will appear on new hardware		55%
Pleased OS desktop features are being developed		10%
ROL and ROOL will eventually kiss and make up		5%
App developments are critical		10%
Dave Holden sleeps easy at night		19%

Discuss this | Archives