In message <5b02388c57basura@invalid.addr.uk>
Richard Ashbery <basura@invalid.addr.uk> wrote:

> In article <mpro.s40kwn032z5am08s1.news@stevefryatt.org.uk>, Steve
> Fryatt <news@stevefryatt.org.uk> wrote:
>> On 10 Nov, Harriet Bazley wrote in message
>> <dc3353015b.harriet@bazleyfamily.co.uk>:

>>> On 10 Nov 2023 as I do recall, Richard Ashbery wrote:
>>>
>>>> Verma reports SharedCLibrary as 6.15 (21 Sep 2022) even though
>>>> I've placed the latest CLib (V6.21 9 Aug 2023) in
>>>> !Boot.Resources.!System.500.Modules as you suggested and
>>>> re-booted. How do I get the system to run the latest CLib?
>>>
>>> I did a full !Boot merge, as I hadn't done one in a long time,
>>> and ended up with C Library 6.21 (09 Aug 2023).

>> The SCL has to be loaded very early on in the Boot sequence
I think it's one of !Sysmerge's roles to make sure that's the case?

> Ahh! that's why the SCL line is high up in the !Run file order. I didn't
> notice this when I first opened !System.!Run file.

>> , as
>> soft-loading it "on demand" by applications is dangerous: it will
>> work once, but the second application to try it in a session will
>> stiff the machine.
But luckily RISC OS is in ROM, I made the mistake by updating with the
wrong one !System:-( (26 bits version)

> When I added another SCL line it didn't stiff the machine but failed to
> boot returning me to the black 'command line' screen hence why I put out
> a warning about modifying !Run files in !Boot.

>> As a result, applications must never soft-load a new SCL from
>> !System. All they can do is test the active version and refuse to
>> run if it isn't new enough for them. This prompts the user to
>> install an updated version into !Boot, which includes lines called
>> early from !Boot.!Run[1] to soft-load the module for the whole
>> session[2].
Yes
> But it's OK to replace old SCL module with latest version in
> !System.500.Modules and then edit the SCL line at the top of the
> !System.!Run file (change 5.66 to 6.19) to force it to run?
> Jean-Michel's instructions were confusing but I think that's what he
> intended. Doing this now runs SCL, V6.21.
Sorry,

>> 1. I'd have to fire up a RISC OS box to check where, exactly.

>> 2. Although anything in the ROM will still use the ROM version of
>> the SCL.

> This not my experience. Excuse me Steve if I'm misunderstanding this
> process.
Me too.
>>>Harriet
>>>I did a full !Boot merge
seems like the right solution?

--
Jean-Michel

On 13 Nov, Jean-Michel wrote in message
<17b894025b.jmb@jmc.bruck.orange.fr>:

> In message <5b02388c57basura@invalid.addr.uk>
> Richard Ashbery <basura@invalid.addr.uk> wrote:
>
> > In article <mpro.s40kwn032z5am08s1.news@stevefryatt.org.uk>, Steve
> > Fryatt <news@stevefryatt.org.uk> wrote:
> >
> > > The SCL has to be loaded very early on in the Boot sequence
>
> I think it's one of !Sysmerge's roles to make sure that's the case?

It is, but Richard didn't use SysMerge as far as I can make out.

> > > 2. Although anything in the ROM will still use the ROM version of the
> > > SCL.
> >
> > This not my experience. Excuse me Steve if I'm misunderstanding this
> > process.
>
> Me too.

AFAIK, ROM components are hard-linked to the ROM SCL as part of the process
of building the ROM. This is completely different to the process used by
applications loaded into RAM, which populate the stubs' jump table when they
initialise. As such, there's no mechanism for ROM components to see a
soft-loaded version of the SCL and link to it.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

In message <mpro.s42rey00l7rot04sw.news@stevefryatt.org.uk>
Steve Fryatt <news@stevefryatt.org.uk> wrote:

> On 13 Nov, Jean-Michel wrote in message
> <17b894025b.jmb@jmc.bruck.orange.fr>:

>> In message <5b02388c57basura@invalid.addr.uk>
>> Richard Ashbery <basura@invalid.addr.uk> wrote:
>>
>>> In article <mpro.s40kwn032z5am08s1.news@stevefryatt.org.uk>, Steve
>>> Fryatt <news@stevefryatt.org.uk> wrote:
>>>
>>>> The SCL has to be loaded very early on in the Boot sequence
>>
>> I think it's one of !Sysmerge's roles to make sure that's the case?

> It is, but Richard didn't use SysMerge as far as I can make out.
I did this and it's not good advice. I wanted to know if it was just the
SCL that was causing an error and I didn't think to update everything.
>>>> 2. Although anything in the ROM will still use the ROM version of the
>>>> SCL.
>>>
>>> This not my experience. Excuse me Steve if I'm misunderstanding this
>>> process.
>>
>> Me too.

> AFAIK, ROM components are hard-linked to the ROM SCL as part of the process
> of building the ROM. This is completely different to the process used by
> applications loaded into RAM, which populate the stubs' jump table when they
> initialise. As such, there's no mechanism for ROM components to see a
> soft-loaded version of the SCL and link to it.

Thank you for this information.
Version 6.15 is dormant. Is the SWI call made on the softloaded version?

--
Jean-Michel

On 13 Nov, Jean-Michel wrote in message
<46c1ce025b.jmb@jmc.bruck.orange.fr>:

> In message <mpro.s42rey00l7rot04sw.news@stevefryatt.org.uk>
> Steve Fryatt <news@stevefryatt.org.uk> wrote:
>
> > AFAIK, ROM components are hard-linked to the ROM SCL as part of the
> > process of building the ROM. This is completely different to the process
> > used by applications loaded into RAM, which populate the stubs' jump
> > table when they initialise. As such, there's no mechanism for ROM
> > components to see a soft-loaded version of the SCL and link to it.
>
> Thank you for this information. Version 6.15 is dormant. Is the SWI call
> made on the softloaded version?

The SWI calls, made by RAM-loaded applications and modules, will be made to
the version of the module which is currently active at the time when the
call is made. If the ROM version is dormant, then that will be the
soft-loaded version in RAM.

Anything which called the SWI before the soft-load occurred will link to the
ROM version of the module, and remain linked to that version after the
soft-load.

The same is true of additional soft-loads. If you soft-load a new version of
the module, load an application which calls the SWI to link up the stubs,
then soft-load a second, newer version of the module, that application will
remain linked to the *first* version which was soft-loaded. Even though the
system will have killed that version off and freed up the RMA space that it
was occupying. This won't be noticed until that free space gets allocated to
a new module or workspace, however, and the library routines get overwritten
with other data.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

In article <mpro.s435j502jos4k04sw.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:
> On 13 Nov, Jean-Michel wrote in message
> <46c1ce025b.jmb@jmc.bruck.orange.fr>:

> > In message <mpro.s42rey00l7rot04sw.news@stevefryatt.org.uk> Steve
> > Fryatt <news@stevefryatt.org.uk> wrote:
> >
> > > AFAIK, ROM components are hard-linked to the ROM SCL as part of
> > > the process of building the ROM. This is completely different
> > > to the process used by applications loaded into RAM, which
> > > populate the stubs' jump table when they initialise. As such,
> > > there's no mechanism for ROM components to see a soft-loaded
> > > version of the SCL and link to it.
> >
> > Thank you for this information. Version 6.15 is dormant. Is the
> > SWI call made on the softloaded version?

> The SWI calls, made by RAM-loaded applications and modules, will be
> made to the version of the module which is currently active at the
> time when the call is made. If the ROM version is dormant, then
> that will be the soft-loaded version in RAM.

> Anything which called the SWI before the soft-load occurred will
> link to the ROM version of the module, and remain linked to that
> version after the soft-load.

> The same is true of additional soft-loads. If you soft-load a new
> version of the module, load an application which calls the SWI to
> link up the stubs, then soft-load a second, newer version of the
> module, that application will remain linked to the *first* version
> which was soft-loaded. Even though the system will have killed that
> version off and freed up the RMA space that it was occupying. This
> won't be noticed until that free space gets allocated to a new
> module or workspace, however, and the library routines get
> overwritten with other data.

So Steve from what your saying the way I've updated the SharedCLibrary
is a seriously bad way to do it. Even though it all appears to be
working it may impact on other software that uses that module.

If I upgrade the !Boot via ROOL's nightly beta HardDisc4 build do I
have to also update the ROM image?

Richard

On 14 Nov, Richard Ashbery wrote in message
<5b032e8ee8basura@invalid.addr.uk>:

> So Steve from what your saying the way I've updated the SharedCLibrary is
> a seriously bad way to do it. Even though it all appears to be working it
> may impact on other software that uses that module.

I thought that you had somehow hacked it into !Boot.!Run, so that it was
loaded at startup? That's what the normal soft-load does, so it's probably
fine; the problems could come when you try to upgrade again, if you've put
different lines into the !Run file.

The requirement is to load the latest version possible, as early as
possible: before anything tries to link to it.
> If I upgrade the !Boot via ROOL's nightly beta HardDisc4 build do I have
> to also update the ROM image?

It's probably wise to keep them mostly in step. However, if it's an R-Comp
system, I'm not going to advise further.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

In article <mpro.s44lii00ijhl803c5.news@stevefryatt.org.uk>, Steve
Fryatt <news@stevefryatt.org.uk> wrote:
> On 14 Nov, Richard Ashbery wrote in message
> <5b032e8ee8basura@invalid.addr.uk>:

> > So Steve from what your saying the way I've updated the
> > SharedCLibrary is a seriously bad way to do it. Even though it
> > all appears to be working it may impact on other software that
> > uses that module.

> I thought that you had somehow hacked it into !Boot.!Run, so that
> it was loaded at startup?

I'm not that clever!!!

> That's what the normal soft-load does, so
> it's probably fine; the problems could come when you try to upgrade
> again, if you've put different lines into the !Run file.

That's a point - I never delete any lines in !Boot obeyfiles but
always prefix the unwanted line with a "|".

> The requirement is to load the latest version possible, as early as
> possible: before anything tries to link to it.

Makes perfect sense.
> > If I upgrade the !Boot via ROOL's nightly beta HardDisc4 build do
> > I have to also update the ROM image?

> It's probably wise to keep them mostly in step. However, if it's an
> R-Comp system, I'm not going to advise further.

Richard