Boot-Desktop file and Configure Look at/Run

I recently wished to change some of the apps in the Boot-Look at and Boot-Run sections of configure. I found that most of the items I had added in the past were now greyed out and couldn’t be removed. Only the most recent changes were still editable. This was the same on both ARMini and Iyonix – both running recent versions of 5.19. After puzzling over this for a while, I delved into the Boot:Choices.Boot.Desktop file.

There now appear to be two sections for the apps/files that are to be booted or run. One of these sections starts eg:
|Start Acorn BootBoot 0.01 Boot
while the other starts
|Start RISCOS BootBoot 0.01 Boot.

In the configure tool the ‘Acorn’ group are the ones greyed out, while the ‘RISCOS’ group are still editable. The same applies to the BootRun section(s).

It looks as if there has been a change in the way the Configure-Boot tool saves its choices, now using RISCOS instead of Acorn, and when reloaded those in the ‘Acorn’ section are no longer editable.

I have not seen any mention of such a change – it can be a source of confusion when user additions become unchangable (certainly threw me for a while). If the entries are manually moved into the RISCOS sections and the Desktop file saved, then on running the Configure tool subsequently, the user additions are once again under user control.

Is this a bug, or have I missed something?

Is this a bug, or have I missed something?

That changed in July as part of a tidy up of the boot system. You may have been doing holiday type things.
Note: The template version of the desktop file sitting in the Hook510 directory uses RISCOS rather than Acorn as of mid-July.

That changed in July as part of a tidy up of the boot system. You may have been doing holiday type things.

That is possible, although I do plough through all the postings on this forum after I have been away to get up to date.

Was the change meant to automagically convert the old Desktop file to the new format, or were there instructions issued to do the ‘upgrade’ by manual editing. If not, how are users meant to deal with the situation of having uneditable entries in Configure-Boot-lookat/run? It doesn’t seem very backwards compatible to me.

Sigh… not again. The format of those lines was first explicitly documented in PRM 5a. With RISC OS 4’s Installer module (documented in the Ursula !Configure Functional Specification) the string “Acorn” effectively became part of the OS API, because the Installer module lets third parties insert blocks in the Desktop and PreDesktop files specifying their position relative to the “Acorn” blocks. The specification even says that software authors can assume the Acorn sections are guaranteed to exist. Changing the name of these sections is as much of an API change as would be – for example – renaming the AcornURI module to be RISCOSURI, just because you felt like it, and damn anyone who has RMEnsured it in their software…

Nevertheless, on at least three separate occasions now, various people have seen fit to “correct” the Acorn reference to a more generic “RISCOS”, with side-effects such as this, where applications that process the file programmatically get tripped up as a result. I usually manage to get it reverted, but this time it looks like it’s made it into a number of releases, so I give up. I guess any application that uses *Install_Merge will need to be changed to permit either term “Acorn” or “RISCOS” now.

Ben: I would have thought reverting to ‘Start Acorn BootBoot the best option, what if any is the downside in reverting’?

I would have thought reverting to ‘Start Acorn BootBoot the best option

No it wouldn’t, as was the conclusion of much thought and analysis.
The origin of the problem is in 2002 when the (RISC OS 5 only) boot sequence was crafted for the Iyonix. It changed the markers to “RISC_space_OS” which was even worse, since spaces are used as the delimiters, ie. “| RISC OS SectionName 1.23” would be split out as

• Company = RISC
• Section name = OS
• Version = 0

Ben’s comment about Ursula spec is a bit moot since Ursula got canned when the Acorn workstations division was closed.

RISC OS Ltd (with RISC OS 4.02 at least, not sure about later versions) used “RISCOS” without a space.

So the options were

• Fall in line with 1999 version of RISC OS
• Fall in line with a version of RISC OS that never shipped
• Continue using a broken section heading from 2002

The first is the least worst.

As an aside, the whole of !Boot has languished in an unloved store cupboard for over 10 years. It’d lost universality, and gained a lot of weight, making it slow (for example loading sprites 3 times over). Volunteers to write an automatic un-boot-frankenstein machine should form a queue behind Chris.

(ref. PRM5a etc)

Ben’s comment about Ursula spec is a bit moot since Ursula got canned when the Acorn workstations division was closed.

So in essence the real requirement is to update PRM5a¹
How many installers actively chuff about with the Desktop and PreDesk files?

¹ People will now start listing the stuff that needs an update. To which the logical answer is – use your keyboard and submit it.

Some interesting comments, Sprow. However, it does mean that RISC OS 5 has been using ‘Acorn’ relatively recently for there to be an ‘Acorn’ section in the Desktop file on my ARMini here.

However, it does mean that RISC OS 5 has been using ‘Acorn’ relatively recently for there to be an ‘Acorn’ section in the Desktop file on my ARMini here.

That was a dimension I’d forgotton in my earlier summary – some of the !Configure tools were writing out “Acorn” sections, and trying to merge with “RISC_space_OS” in the template ones provided in the various hook directories, and failing (actually, the merge would duplicate the sections rather than failing loudly).

RISC OS 5 has been using ‘Acorn’ relatively recently

Indeed, the missing piece of the jigsaw is that Castle didn’t keep the disc image under source control, so what’s in CVS doesn’t reflect what actually shipped on most (all?) the production Iyonix PCs.

Another complication is what happens for people who try softloading RISC OS 5 on RISC OS 3 Risc PCs – they will still have the PRM-era boot sequence which uses the string “Acorn”. Many of those will have had the nested Wimp installed; while it predated the Installer module so couldn’t use it, I believe the installer for the nested Wimp relied on the string being “Acorn” as well.

Does anyone have one of the early Iyonix boot sequences which use the “RISC OS” string with the space? Mine ought to be a fairly early one, and it has files in the RO500Hook directory using the “Acorn” string instead, dated 14 Nov 2002, so it should have been fixed at least by that point. The presence of the space would, as Sprow says, completely confuse all current versions of the Installer module, but I’m hoping it’s rare enough that we needn’t worry about it.

Does anyone have one of the early Iyonix boot sequences which use the “RISC OS” string with the space?

You mean for testing? The answer to that would be to look at the content of the CD and pull the copy of the boot sequence from that. All registered users were sent a copy so there should be plenty around.

Does anyone have one of the early Iyonix boot sequences which use the “RISC OS” string with the space?

All of them do, at least according to CVS (quick disclaimer: my check in comment says “storing this stuff” as I didn’t make the change!).

Another complication is what happens for people who try softloading RISC OS 5 on RISC OS 3 Risc PCs

Not really a complication, the universal boot sequence isn’t trying to be multiboot (that’d be massively more complicated!), so once the given ROxxxHook template has been copied into Choices you’re frozen in that era. RISC OS 3 doesn’t use the configure plugin model, so all the 3xx hooks use ‘Acorn’.

according to CVS

When I said it wasn’t kept under source control, I mean that the exact version that people had shipped on their hard discs / CDs didn’t all make it into CVS. Anecdotal evidence from others above would seem to suggest it’s not just me imagining it.

I don’t personally have a copy of the CD to confirm against – one of the side effects of being on the development team is that I never had the cardboard box, the manuals and all the other bumph that comes with a retail unit…

I have managed to find a CD, which I think is RISC OS 5.03. In the Desktop file in RO500Hook everything is ‘Acorn’, no sign of RISCOS with or without a space. The PreDesktop file is the same.

PreDesktop file is dated 14 Nov 2002 and the Desktop file is dated 31 Mar 2003.

So in essence the real requirement is to update PRM5a1

Having taken a little time to read PRM5a, in the version I was reading it specifies the format of the string but not the content except that the marker varies with author.
In essence it seems that if a third party produces a merge tool it ought to mark the merge in items with the third party authors marker thus ensuring that the normal boot tools do not see it as a removable element. No one thought that the OS author name might change to a more generic form.