markee174
27/11/07 7:32PM |
At last!!! |
hzn (+1.0)
27/11/07 7:52PM |
Good! |
Col1 (+2.0)
27/11/07 8:20PM |
Its a small step- but one in the right direction.  |
lym (+2.0)
27/11/07 10:14PM |
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. |
rjek (+1.0)
27/11/07 10:17PM |
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? |
sa110 (+1.0)
27/11/07 10:23PM |
In reply to rjek:
Perhaps now RISCOS 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? |
JGZimmerle (+1.0)
28/11/07 7:44AM |
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. |
rjek (+1.0)
28/11/07 8:08AM |
In reply to 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. |
druck (+1.5)
28/11/07 8:59AM |
"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. |
sascott (+1.0)
28/11/07 9:03AM |
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. |
coling (+1.0)
28/11/07 2:26PM |
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. |
hubersn (+1.0)
28/11/07 4:02PM |
In reply to 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). |
sa110 (+1.0)
28/11/07 5:39PM |
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. |
VinceH (+2.0)
28/11/07 8:54PM |
In reply to 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. |
druck (+3.2)
29/11/07 8:53AM |
In reply to 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. |
philipnet (+2.0)
29/11/07 9:16AM |
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. |
jess
29/11/07 9:34AM |
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.) |
rjek (+2.0)
29/11/07 10:39AM |
In reply to 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. |
philipnet (+1.0)
29/11/07 10:44AM |
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. |
VinceH (+1.0)
29/11/07 11:43AM |
In reply to 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 (+1.0)
29/11/07 11:56AM |
In reply to 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. |
mripley
29/11/07 12:12PM |
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 RISC OS. 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. |
jess (+1.0)
29/11/07 3:06PM |
In reply to 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.) |
rjek (+1.0)
29/11/07 3:17PM |
In reply to 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.) |
jess (+1.0)
29/11/07 3:36PM |
In reply to 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) |
lproven
30/11/07 12:15PM |
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? |
druck
30/11/07 1:11PM |
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. |
| 3 comment(s) are below your moderation threshold. Login to view them. |
| Use the forum for more comments on this article |
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.