At some point I suspect DesktopBoot would benefit from being split up as it's a bit of a dumping ground right now, and at that point ROMPatch would get its own VersionASM file for such purposes.
Back here in reality, yeah, let's bump VersionString
manually.
Does the VersionString
constant in DesktopBoot/Source/ROMPatch/s/module get updated automatically, or will that need to be handled manually?
ROOL (0c0ff5e5) at 20 Feb 20:27
Updated the IfThere utility to add header/footer mark
Subsequently I realised SoftLoad could be moved to !Boot.Resources, and rather than relying on number of !'s in order to boost the order, the !!SoftLoad obey file could be removed entirely and an IfThere in BootRun looking if SoftLoad exists and running it before PreDesk (but after SetChoices).
The moving of SoftLoad out of Choices, is complete.
In order to simulate the idea of having 2 different !Boot.Choices.Boots I added Wipe <Choices$Write>.Boot ~C~VFR
in Loader
just before the softload ran (brutal!) which happily booted from any of the RISC OS 3 ROMs into RISC OS 5.
Derived from RO520Hook.
ROOL (5434f75f) at 12 Nov 17:31
Import of RO530Hook
Derived from RO520Hook.
This is a possibility when softloading RISC OS 5 on a RISC OS 3.7 machine, due to the way that !Boot.Choices is initialised on first boot.
Appended to !8
This solves a handful of minor issues compared with having it in PreDesk
ROOL (58659c37) at 07 Nov 20:45
Integrate check for optional ROM softload
Tested here and ok on Titanium with 5.24 in ROM and RPCEmu with various RO 3, 4 & 5 ROMs
This solves a handful of minor issues compared with having it in PreDesk
I should point out that another issue with the current implementation is that because the contents of !Boot.Choices.Boot is only populated on first boot, it won't be kept up to date when further updates are made to components like ROMPatch.
That's true, those binaries get 'trapped' in the live copy, and would only get copied over from the hooks if you actively deleted the entire Choices.Boot. Coping with the possibilities there isn't ever going to be pretty - what happens if we remove an item from Hook, do we also need to remove it from the live copy?
I suggest parking that for now as it's a pretty rare event (the hooks are reasonably static on the whole). We have !ResetBoot as the scorched earth solution, and the Installer module could maybe help out.
An alternative solution here could be to split it up into two separate parts, where the components that would usually be edited by the user or by !Configure are copied from a generic template that's suitable for all OS versions
That's kind of the intent already. Things in Choices.Boot are edited and the Hooks are not. I don't think it would be possible to come up with a generic blank set, for example the sound mixer settings (managed by Sound Setup) vary by OS version, as do the capabilities of pinboard etc etc. Also, the basic dir structure needs to stay the same because of all those !Boot updates in the wild that expect to be able to be merged.
- Add a !!SoftLoad obey file which just runs
SoftLoad.Prompt
(this ensures it's run first on PreDesk)- Rename !!SoftLoad the directory to SoftLoad obviously
Subsequently I realised SoftLoad could be moved to !Boot.Resources, and rather than relying on number of !'s in order to boost the order, the !!SoftLoad obey file could be removed entirely and an IfThere in BootRun looking if SoftLoad exists and running it before PreDesk (but after SetChoices).