The Sinclair QL Forum

Peter wrote: Sun Jan 19, 2025 7:27 pm

pjw wrote: Sun Jan 19, 2025 5:01 pm Most programs, I believe, dont include the runtime but expect it to be pre-loaded at boot.

Opposite for me, all QLiberated programs I use include the runtime.

RalfR wrote: Sun Jan 19, 2025 9:30 pm It actually makes more sense to load the runtimes residently, as you save a lot of storage space, even if that is no longer a problem these days, except perhaps on a QL.
But it also has the advantage that the loaded version applies to all QLib programs...including errors of the runtimes.

There are still a lot of programs out there which have v3.22 of the runtimes linked (View the file, it is always near at the start). You should definitely edit them with the Minerva tool to make them use resident runtimes.
You actually have to test that too: Which runtimes are in the program, if any are linked? Very often it is v3.22, how do they react on the Q40? Or even earlier versions? Which QLib version did the error occur, or was it there from the beginning? There's a lot to test.

I've now tried the whole thing again with QTrans to verify that Minerva's "QLibodge_bas" actually prevents linked runtimes. So applied the program to QTrans and then ran Mark's program again.
Of course, his program still finds the location, the runtimes are of course still in the code, but after his patch, QTrans starts without any problems. So the Minerva program obviously works and QTrans used the resident runtimes.

Peter wrote: Sun Jan 19, 2025 10:18 pm Static linking of the library has the advantage that a program won't break after a library update. With dynamic linking, one can easily get into a situation where different programs need different library versions to function correctly. That mess can get larger than the memory saving is worth. Static linking brings simplicity, so I can understand that some writers prefer that method. (I wish those writers had not used QLiberator at all, but that's a different story.)

RalfR wrote: Mon Jan 20, 2025 6:37 am

Peter wrote: Sun Jan 19, 2025 10:18 pm Static linking of the library has the advantage that a program won't break after a library update. With dynamic linking, one can easily get into a situation where different programs need different library versions to function correctly. That mess can get larger than the memory saving is worth. Static linking brings simplicity, so I can understand that some writers prefer that method. (I wish those writers had not used QLiberator at all, but that's a different story.)

In principle I agree with you, but I don't think there are very many of them in QL circles. Tools like the Runtimes and Menu extensions are used by many programs. You can even load things like QPTR and ptrmen_cde resident. Otherwise 10 programs are running and they all have this in the code. What a kind of overhead.

It's good that at least no one has come up with the idea of ​​including the menu extensions in the code yet...

tofro wrote: Mon Jan 20, 2025 10:28 am <> Self-contained programs are just easier to install and run for beginners, and most modern platforms have plenty of memory to waste.
<>