!boot - does it have to keep the same name?

It seems to me that if you are softloading differents version of RISC OS, having different !boots would be helpful.

Would it be possible to have an option of using a different folder? (eg a parameter supplied optionally when softloading)

I think there are basically two ways we can go about this:

1. Update the softload tool so that it swaps the active !Boot sequence before starting the new ROM
2. Produce a new universal boot sequence, which works sensibly with RISC OS 3/4/5/6 and doesn’t complain if you keep changing versions

Although option 2 is attractive, option 1 may be better, especially as it would allow easy testing of new/updated !Boot components

From your answer, I take it that the name !boot is pretty hardwired into the ROM and not easier to change.

Another option might be to allow partitioning, and then have RO 5 able to use the !boot on a different partition.

Well, it’s fairly easy to change it in the ROM, but at the moment there’s no way to pass an argument string or any other kind of parameters to the ROM in order to indicate which !boot to use (although the softload tool could always fall back to directly editing the name in the ROM image if it knew where it was). Editing the ROM or passing a parameter isn’t a solution that would work for all situations, either – getting it to work with RISC OS 5 would be easy since we’ve got the source code, but for RISC OS 4/6 support ROL would have to implement it themselves. It’s also a solution which wouldn’t work well with any ROM images which are older than the latest development versions of 4/5/6, simply because noone is going to go to the trouble of recompiling and releasing the old ROM images with support for the new booting options.

There’s also the issue of what would happen if you had multiple !boot folders all sat in the root of your hard disc. I think the “No !boot sequence has been run” error message is triggered by !boot.!boot, so if you wanted multiple boot sequences to coexist they may need modifying so that they don’t all trigger error messages when you open the root folder.

Another thing to consider is that there’s a fair amount of the boot sequence that will work fine on different OS versions – e.g. system, scrap, and most of the choices folders. If people use softloads on a daily basis then they might appreciate a system which doesn’t require them to duplicate those folders.

Another thing to consider is that there’s a fair amount of the boot sequence that will work fine on different OS versions – e.g. system, scrap, and most of the choices folders. If people use softloads on a daily basis then they might appreciate a system which doesn’t require them to duplicate those folders.

That’s a good point.

Additionally, if the whole boot sequence is to be redesigned it might also be an opportunity to address some of the following issues (some of which may already be listed in another post, but I didn’t spot anything just now while doing a quick search):

• “Hiding” the display of !Boot in the root directory, to prevent users from inadvertently moving its contents elsewhere or otherwise messing things up¹
• Restore previous settings, e.g. if a duff MDF is used and the keypad boot-up sequences don’t help
• Replacing the DeskBoot sequence with a more meaningfully named configuration application (possibly also “hidden” and accessible from the iconbar instead)

(Well, this is the Wish lists forum, after all…)

¹ I know it sounds horribly Microsoft, and don’t know how it would be implemented easily… perhaps the structure could be something like

- $
- $.HardDisc4
- $.HardDisc4.!Boot [called, e.g. BootFS]
- $.HardDisc4.!Configure [called, e.g. Config]
- $.HardDisc4.Root [called, e.g. RootFS]

getting it to work with RISC OS 5 would be easy since we’ve got the source code, but for RISC OS 4/6 support ROL would have to implement it themselves. It’s also a solution which wouldn’t work well with any ROM images which are older than the latest development versions of 4/5/6, simply because noone is going to go to the trouble of recompiling and releasing the old ROM images with support for the new booting options

I was only really thinking in terms of future images. Because as far as I can see, you are unlikely to need a choice of !Boots for minor revisions anyway. (unless it is a developer with special tracing facilities in an alternative boot.)

I was thinking more of the situation where someone has a 3.x or 4 system that they may need to keep as is, for compatibility. They would be able to play with RO 5 without changing their working system, while it is still unstable, and dual boot, once it is stable.

If we are talking about changing !boot, I would like to see it read only, in an archive (read by an image filing system in ROM). With seperate resources, choices, and scrap. On a machine with lots of ROM the whole !boot could be in ROM. (In effect back to how RO 3.1 originally worked from the user perspective.) Ideally scrap would use spare RAM, and just use disk space when that runs short.

It seems to me that if you are softloading differents version of RISC OS, having different !boots would be helpful.

Would it be possible to have an option of using a different folder? (eg a parameter supplied optionally when softloading)

Some time ago I produced a program called MulBoot which was mainly intended so that I could run RO4/6 on the same machine easily. It works by storing the inactive ’!Boot’s inside its directory.

It’s available from http://www4.webng.com/resurgam/ Is this the sort of thing you were thinking of?

it’s the same sort of functionality, but what I was thinking of would allow a softloaded OS with no change to the existing boot. ie you run the softload, it provides the new OS with the name and location of the boot app to use. ie drop in the softload and the new boot ap in the root directory, run the softload, and that’s it.

If it is a horrible change to do, then your system would be more sensible.