Configuration - Boot/Run at Startup

Configuration Boot and Run-at-startup file location paths are greyed out with the Boot from HardDisc4 dated 23-10-12 when compared to a Boot dated 28-07-12. Removing a path to a program is therefore impossible. The RunImage in !BootApps, !BootBoot and !BootRun have changed. If the original RunImages (28-07-12) are substituted then the paths can be edited. Should I have done this and if so why is it necessary?

BB running RISC OS 5.19 (29-Oct-12)

Perhaps you should look at this thread: https://www.riscosopen.org/forum/forums/4/topics/1441

Should I have done this and if so why is it necessary?

There was a change, as mentioned in another thread,¹ that changed the lines in PreDesktop and Desktop (both in the "!boot.choices.boot directory).
The text “Start Acorn” in those files was changed to “Start RISCOS” and the system, in the RunImage files you changed, is expecting RISCOS in the new version and Acorn in the old.
Change the RunImage files back to the new version and change all instances of “Start Acorn” to “Start RISCOS” and the entries will be ungreyed.

¹ Back in July. “Start RISCOS” matches the behaviour of ROL sourced versions (as well as reflecting the fact that Acorn are no longer around)

Sorry about that Chris. Yes I have just seen your original question. I will have a look. I still haven’t got my head around the ROOL forum and stupidly didn’t look in most obvious place – Bugs

There was a change, as mentioned in another thread,1 that changed the lines in PreDesktop and Desktop

Thank you Steve for the clear and concise information for editing the above files. Having done this the ‘Configure.Boot’ entries are no longer greyed out. Presumably these changes will be reflected in future ROM/HardDisc4 releases.

Presumably these changes will be reflected in future ROM/HardDisc4 releases.

Already are I believe. In the intervening time I checked the content of a standard RO4.02 install and it too has a Start RISCOS entry rather than the “Start Acorn” I think somehow the Start Acorn came through the PACE era and missed the ROL initiated change of 4.02. Given that the 4.02 code was supposed to be passed back to PACE by ROL I don’t know why this one happened.
Perhaps the RO5.19 code needs a small routine to swap any Acorn entries to RISCOS.

Slow response – fingers a bit numb as Coleshill cemetary seems a bit wet and chilly.

All 4.02 code and some later did go back to Pace from ROL but AIUI only small proportion was included in Pace’s builds.

All 4.02 code and some later did go back to Pace from ROL but AIUI only small proportion was included in Pace’s builds.

It would be nice if all the later code went into the CVS.¹
It seems ROL have given up on the commercial aspect.

¹ It would certainly make compatible updates of RO5.xx a lot easier

I don’t know if Pace passed on to Castle/Tematic/ROOL all the code ROL gave them. Passing over any other code is another matter.

I don’t know if Pace passed on to Castle/Tematic/ROOL all the code ROL gave them.

The purchase of the IP and rights would have involved handing over all of the property. The text kicking around at the time (from PACE) was to the effect that they retained the right to use (under license) and continue to develop (under license) their specific branch for use in embedded systems of their manufacture.

Passing over any other code is another matter.

Indeed, however if the commercial use of the later code is defunct (I don’t think that OS version will run on any modern kit) then making the code available for possible integration would be a nice gesture to the RO users in general. The few long term users have suffered bad times, a few good times are in order.

I think it might be nice if things like the Pi based machine from CJE could use any useful developments. Or the Beagle based machine from R-Comp, or even a speculative Arndale based desktop machine.
Do you disagree?

Anything concerning the integration of ROL code sounds like asking for trouble if you ask me.

I apparently don’t have the priviledge to delete my own posts forever, what chance spams?
I guess this rubbish will be hanging around mocking us, like that Qatada guy.

then making the code available for possible integration would be a nice gesture to the RO users in general.

It would be a very nice gesture, and God knows it would sort out diversion incompatibilities due to the two branches going in different directions; not to mention giving some faith and respect to certain individuals that their hard work still has purpose instead of what appears to be a branch of the OS no longer being developed (does the RO6 32 bit stuff work on any of the newer devices?).

However… in certain shady alleyways, you start to talk about these things and there’s a definite chill in the air. I kind of expect to see stringy-haired-ghost-girl appear at any time…

It would be a very nice gesture, and God knows it would sort out diversion incompatibilities due to the two branches going in different directions; not to mention giving some faith and respect to certain individuals that their hard work still has purpose instead of what appears to be a branch of the OS no longer being developed

I read that and the first image in my mind was a human apendix¹ – absolutely no function apart from causing problems. It would be a massive shame if thats all it became known for.

(does the RO6 32 bit stuff work on any of the newer devices?).

Haven’t people loaded the toolbox modules or something? Mind you the problem is that a proportion of the applications that demand the ROL version number modules have other 32 bit or alignment issues. That just mixes things up and people assume the problem is the modules. Of course, while the only legitimate source for those versions or modules with those features is a site could just vanish it’s hardly prime developer material.

¹ Too long working at a hospital

The purchase of the IP and rights would have involved handing over all of the property. The text kicking around at the time (from PACE) was to the effect that they retained the right to use (under license) and continue to develop (under license) their specific branch for use in embedded systems of their manufacture.

Whether they should or shouldn’t have passed things on depends exactly on the contract. But not ALL source code they had may have been handed over, even if it technically should have. ROOL can only work with what they actually have.

Next line should be double quoted but I can’t get it to do so.
Passing over any other code is another matter.

Indeed, however if the commercial use of the later code is defunct (I don’t think that OS version will run on any modern kit) then making the code available for possible integration would be a nice gesture to the RO users in general. The few long term users have suffered bad times, a few good times are in order.
.
I think it might be nice if things like the Pi based machine from CJE could use any useful developments. Or the Beagle based machine from R-Comp, or even a speculative Arndale based desktop machine.
Do you disagree?

I would love all the Select features on our PandaRO & RaspberryRO but knowing the current situation I’m not holding my breath. For that to change quite a few people would need to agree to it.
I personally invested thousands of pounds into keeping RISC OS going by investing in RISC OS Ltd, others invested considerable more. I quite understand their reluctance to not only walk away from their investment but to give it to Castle, which is what they would need to do, for it to be of any real use.
Then there are the programmers who contributed to RISCOS Ltd’s RISC OS under the agreement that they granted rights to RISC OS Ltd to use their work.

I’ve seen quite a few postings talking about the above situation, their tone would more than probably harden people’s reluctance to give code to Castle, so please no more here.

but knowing the current situation I’m not holding my breath.

Ho hum.