Peter wrote: Sun Aug 31, 2025 9:38 pmAt the moment I use only QLib programs which already have a built-in in runtime
The solution is actually quite simple: simply load "QLib_run" in the boot program, then everything will work....
Not reliably, because there were different versions of "QLib_run". If the library is contained in the executable, I'm sure to have the right one.
Also I don't like to always load extensions that I may not always need, especially messy software like QLiberator.
pjw wrote: Tue Sep 02, 2025 3:29 pm
It works a treat, Martin, at least on the program I tried it on. Thank you
The removal program appears to remove 114 bytes more than the size of the Qlib_run I just compiled into it. Is that normal?
Adding it again using your program restores the object to the "correct" size, ie 114 bytes less than the compiler managed.
Either way, the object program worked as it should.
I don't know offhand what the 114 bytes are. For my testing I have three programs that I have compiled twice, once with the runtimes included, and once without them.
Then after using one of my programs, I do a byte for byte comparison with it's opposite number to make sure they were exactly the same.
Are there any other QLib utilities that are wanted? I don't mean improvements to QLib itself, but things like the add/remove runtimes programs.
Having said that, There is mention in the user manual on the subject of the 'Trace' option, of a possible 'debugger' for QLib programs. Is there any interest in one of these? What features would be wanted?
I think it would involve a replacement runtimes module.
A trace and debugger module allowing single stepping (as the manual suggested) would certainly be useful.
I see the manual hints that, for example, "TRACE occupies the first reserved entry in the QLIB_USE parameter list". If such "hooks" already exist in the code to some degree, it gives you a starting point as to how to go about implementing it.
