Sof loading BASIC

Thanks for the explanation Jeffrey, Task windows are the crux of the matter. Everything else will be at the return from the SYS handler and I’m pretty sure that can handle BASIC being changed mid flow.

And if it’s the case it’s better to adjust things, than to create new mechanisms that will finish in a “module hell” phenomena (see the unsolvable “dll hell” problem in windows).

There may also be references/dependencies on the module’s RMA workspace (currently none)

If there is a workspace that, too, would have to be ‘orphanned’, but BASIC does not have one, so not needed.

ResourceFS files (softloaded BASIC registers & deregisters files on init/shutdown), etc.

I thought about Resources, but as the module code remains in place, so does the Messages file data, even if it is Deregistered. The descriptor block should still be valid as it points directly to that data.

My RFSFiles module has a switch to keep files in memory for just this purpose.

A much more sane solution would be to ‘orphan’ the current BASIC module. Allow current programs to continue to use it, but make it inaccessible to any new programs that try to start. The same tactic could be used for some other problem areas, like CLib.

If there were an official mechanism for ‘orphanning’ then SoftBasic would not be even a consideration. ;-)

And if it’s the case it’s better to adjust things, than to create new mechanisms that will finish in a “module hell” phenomena (see the unsolvable “dll hell” problem in windows).

As it stands, this is just about using new versions of BASIC on machines that have earlier versions in ROM. Despite what Rick said, I think the parallel CLib problem has been resolved for a long time. I do not think that it will finish in a “module hell” unless someone thinks to apply a similar idea to modules generally.

I said about RMEnsure:

this might not really be a problem, but not for the obvious reasons.

If there is only one soft-load version of BASIC in !System then if there is a RMLoad it will always be the same file.

After the checks mentioned by Rick, RMLoad first causes the previous version to be RMKilled and the memory returned to the RMA heap. Then the space for the new file is claimed and the module loaded and initialised. For an identical module this memory will be the same as has just been released.

All will be well, or will it?

I do not know enough to answer, but can imagine there might be problems, say, if an interrupt causes a piece of code to claim a block in RMA between the release of the old module and the claim for the new.

Is this a problem that could affect SoftBasic?

Does BASIC still support being built as a standalone application space program rather than as a module? It used to. If so, that’d be a good way to supply a BASIC that’d work across all the OSs that Jon wants to support for the partition manager.

Does BASIC still support being built as a standalone application space program rather than as a module? It used to.

If it did, that was before Arthur, I think. Richard’s BB4W does this, of course, incorporating the interpreter within the runtime.

Something vaguely like this was in my mind and I think SoftBasic could be written to juggle modules so that the status quo was restored after the application was using the new version

That is if it is not too ‘dodgy’. Other weird ideas are on offer. ;-)

Despite what Rick said, I think the parallel CLib problem has been resolved for a long time.

I don’t. Because clearly there are people around who do not want to update old versions, hence why the spectre of StubsG crops up from time to time.
Doing an RMEnsure CLib 5.xx RMLoad CLib may work if they’re using the one supplied in ROM, but if it ever got updated at all, then expect everything to instantly fall over in a heap.

It’s worth noting that one of the first things the boot sequence does is try to softload the version of the library in !System. What does Select’s boot do?

I do not think that it will finish in a “module hell”

We’re generally immune to module hell as the OS keeps track of modules by name, not version.

If there were an official mechanism for ‘orphanning’

It might be a little harder than it seems. If you fiddle things to orphan old BASIC to load a newer one… Who responds to *BASIC?

Commands are processed somewhere else, as I’ve had times when the machine has responded to commands in a module that is no longer present, but obviously something went won’t with the unlinking. Worse, loading the module again didn’t fix things, the commands were passed to the old code (which, obviously, crashed).

All will be well, or will it?

To tie up this topic, I have convinced myself that as long as we follow the precepts laid out by Martin, with only one copy of a soft-load BASIC in !System, then all will be well. There should be no need for SoftBasic and its ‘dodginess’. ;-)

with only one copy of a soft-load BASIC in !System, then all will be well.

Oh, yes. If people want to run modern software, they should upgrade to suitably modern resources.

Now if only we could sort out the StubsG nonsense… ;-)

Now if only we could sort out the StubsG nonsense… ;-)

As I said elsewhere StubsG is an example of a solution looking for a problem.¹
There was no difficulty loading the most modern SharedC on the oldest systems that could conceivably need it, so there was no problem that required StubsG

Running through other recent topics allied to this:
Soft-loading BASIC? As above, ensure there is only one.
Mimemap? – Ensure there is only one.
Certificates? Ensure there is only one.
Libraries – Ensure there is only one.

Anyone not see a pattern?

¹ I suppose it could be listed, possibly unkindly, as a fit of pique.