Help with Q Liberator

[dilwyn]

A "bad parameter" in the context of an executable usually points to the loss of an executable file header somewhere.

In other words, when you transferred the executables into your microdrive image or win1_ something happened to lose that little header part which distinguishes between executables and standard data files/BASIC programs.

Since this happens at the point at which the compiler tries to compile from the work file, it's highly likely the header got lost at some point.

Can you try this command and tell us if you got a 'bad parameter' error from it:

(use mdv1_ or win1_ depending on where the file is located)

EXEC win1_QLIB_obj

It will need the QLiberator extensions installed first (if it says "Runtimes missing!", extensions are not installed before you typed the command). If successful you'll see the compiler's "panel" window, the one where you enter the filenames manually.

If the EXEC command gives 'bad parameter" it confirms loss of file header and you'll need to go back to looking at the QL2K file transfer tools to work out how to install with header. It's a long time since I used QL2K and I just can't remember enough about them to give step by step instructions.

[gregtaylor]

Hi Dilwyn,

Looks like a lost header. I am downloading from your site where files are set by windows equirements, e.g. qlib.obj then downloading to a qlib directory then renaming to qlib_obj. Is this where I am going wrong?

Greg

[dilwyn]

Hi Dilwyn,
Looks like a lost header. I am downloading from your site where files are set by windows equirements, e.g. qlib.obj then downloading to a qlib directory then renaming to qlib_obj. Is this where I am going wrong?
Greg

(retyped after the bloody Forum timed out and yet again lost my original reply after spending an hour on it before I submitted it)

That's right, the name needs to be qlib_obj, not qlib.obj

Looks like it might be the file header problem then. If you have Toolkit 2 installed on your emulator, you should be able to verify this by using an FTYP function to check the file type of the executable. Assuming your compiler is in WIN1_ type this into QL2K:

PRINT FTYP(\win1_QLIB_obj)

(note: backslash between the open bracket and the filename - even this might fail if the Toolkit 2 is so old that functions like FLEN, FDAT, FTYP fail to recognise the backslash parameter).

If this returns 1, the header is OK. I am now at a loss as to what is going on and will be unable to be of any more help.

If it returns 0, the header is lost during transfer. In that case, read up on handling executable file headers in non-QDOS filing systems - learn how to walk before trying to run. NEVER unzip QL executables into a non-QDOS filing system unless you know how to restore and handle headers. I'll add a little program below to restore the lost QLib_obj header in this case.

(Explanation of types: 0 is a data file, e.g. a text file, or a SuperBASIC program, or just any old data file, type 0 is unaffected by the headers issue. 1 is an executable program - the type you start with EXEC or EXEC_W commands or equivalents in various toolkits, 2 is the little used SROFF or Sinclair Relocatable Output File Format used by assemblers/linkers).

The reason why almost everything online for QL is zipped, apart from bundling everything into one file, is to preserve executable file headers. Not many systems can handle these headers in a non-QDOS filing system, so it is always easier to download the zip file, transfer it into the emulator, unzip there and copy the files to where you want after that.

(if you are in a catch-22 situation of being unable to unzip something because you can't get a copy of unzip onto your system first without losing its own header, try the special versions under Job2Bas on my website at https://dilwyn.theqlforum.com/arch/index.html - these are BASIC versions of unzip unaffected by the headers issue, when run they recreate a proper executable version of unzip for you within the emulator)

QLay and QL2K are possibly the worst of all emulators to use in this respect - it has its own unique way of doing things and you really have to master the QLAYT tools for transferring files into the emulator's WIN filing system. Heavy work. I don't remember if they transfer the file headers into the QLay/QL2K filing system or just tell you what they are and leave the header restoration to you.

It's a long time since I last used QLay or QL2K, so I'm going to say something I don't know is true or not. I suspect it'll be easier to copy the zip file itself into the emulator's directories after downloading something and doing the unzipping within the emulator using the QDOS version of Unzip.

There is a way of restoring the file header manually for Qlib_obj in the emulator environment by using the SEXEC command, which is what I suspect may need doing in your case. Assuming you are certain that you are using v3.36 of the compiler, try this. The numbers in the command would vary from version to version (I took these from the v3.36 on my website). This needs Toolkit 2.

Code: Select all

100 base=ALCHP(46158)
110 LBYTES win1_Qlib_obj,base : REM load the "lost header" version
120 SEXEC win1_Qlib_obj,base,46158,20386 : REM save a new version with restored header
130 RECHP
140 PRINT"Program finished."

the 46158 is the length of the compiler file, the 20386 is the amount of dataspace it needs. The dataspace part is what goes missing when headers are lost.

Be very careful with the above little program, one typing mistake could damage your copy of the compiler!

[gregtaylor]

Hi Dilwyn,

What a fantastic reply. As you predicted FTYP returned 0 and running your program has fixed QL Liberator. My utmost thanks!!

Have spent the afternoon reading about headers. FOund an easy way to determine file length is to open#10,file then PRINT FLEN(#10) remembering to CLOSE#10.

I decided to try to fix the turbo compiler. Found the souce files on your excellent web site and found the data sizes in the two executables. Plugged that into your little program and Turbo now works as well.

Thank you for all your help and sorry you had to type it in all twice. I do think the forum timeout is too short.

Greg

[dilwyn]

Excellent!

And if your Toolkit 2 version supports the backslash parameter (only very old ones don't), an even quicker way to check the length of a file is:

PRINT FLEN(\filename)

The Forum timeout being short is one thing.

1. It doesn't timeout until you press SUBMIT, even if you were typing seconds before pressing SUBMIT.
2. Then it asks you to log back in
3. Then you find the message you typed is lost and you are back at the editing screen, but without the message.

Worst possible combination of way of doing things, really lulls you into a false sense of security. You can copy and paste the text into an editor just before pressing SUBMIT but it's a real pain having to do that every time "just in case". I tried writing posts in an editor but then you have to manually add links, CODE sections, attachments etc so that's no substitute either unless it's a straightforward text-only post.

[XorA]

Excellent!

And if your Toolkit 2 version supports the backslash parameter (only very old ones don't), an even quicker way to check the length of a file is:

PRINT FLEN(\filename)

The Forum timeout being short is one thing.

1. It doesn't timeout until you press SUBMIT, even if you were typing seconds before pressing SUBMIT.
2. Then it asks you to log back in
3. Then you find the message you typed is lost and you are back at the editing screen, but without the message.

Worst possible combination of way of doing things, really lulls you into a false sense of security. You can copy and paste the text into an editor just before pressing SUBMIT but it's a real pain having to do that every time "just in case". I tried writing posts in an editor but then you have to manually add links, CODE sections, attachments etc so that's no substitute either unless it's a straightforward text-only post.

Something on your machine is either deleting the cookies, or your IP is changing every few minutes!

[gregtaylor]

We have been having trouble with computers losing the internet for short periods. This might explain it! Thank you for the heads up and the extra tip.

Greg

[dilwyn]

That's my browser's cookie settings.

Always had this problem with the Forum, never with other sites.

Cookies

[XorA]

That's my browser's cookie settings.

Always had this problem with the Forum, never with other sites.

cookies.jpg

Do you have some bonus ad blocker, virus checker, firewall software though. As none of the moderators can repeat your problems?

[dilwyn]

Just the usual Windows Defender (or whatever the inbuilt AV is called nowadays in Win11) and ICBM Security Rapport, the recommended thingy for my internet banking.