Q_Liberator malaise

[pjw]

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.

Sorry, I should have written "Most sensible programs.." but ah, I just assumed.

[RalfR]

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]

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.)

[pjw]

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.

Wheres the "thumbs up" smiley?

[RalfR]

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...

[Derek_Stewart]

But does it work on a 68060?

I do not have any working Q60 boards, still trying to debug a Q40 that freezes after 5 minutes. Maybe faulty CPU.

[tofro]

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...

That decision directly depends on how many "Just downloaded your xyz program and it won't run"-e-mails you want to enjoy. Self-contained programs are just easier to install and run for beginners, and most modern platforms have plenty of memory to waste.

Programs targeting the black box machine are a bit different, memory tends to become scarce, even on GC and SGC setups, once you load a number of toolkits. I agree you don't want to have multiple copies of libraries and toolkits loaded there. So maybe it's best to supply both: A self-contained version and a version that uses shared runtimes. Even better: Supply the source code, then the end user can decide.

[RalfR]

Here is the program with which you can, so to speak, "switch off" the linked runtimes in a QLib program. The program expects TK2 and the QLib Runtimes. I just changed the look a bit.

[pjw]

<> Self-contained programs are just easier to install and run for beginners, and most modern platforms have plenty of memory to waste.
<>

If a Qlibbed program without the runtime baked in is run on a system without the runtime loaded you get an error message "Runtimes missing!" or words to that effect. Same with Turbo.

If someone doesnt know what that means, the natural next step would be to check the included documentation which presumably would enlighten one.

No programmer can protect against a complete idiot! And we have to assume that no idiots would be interested in a QL in the first place

[RalfR]