QLiberator decompiler

Anything QL Software or Programming Related.
User avatar
Ralf R.
Gold Card
Posts: 273
Joined: Fri Jun 15, 2018 8:58 pm

Re: QLiberator decompiler

Postby Ralf R. » Sun Jan 19, 2020 9:46 am

Martin_Head wrote:One zip file is a floppy disk image, and the other, is the files on the floppy image, all zipped up.

It is important to know, that if one wants to put the IMG onto a 720k 3,5" disk with one of the free programs under Windows, the name has to be not more than a few characters, e.g. QLib8.IMG.

If it is as Martin supplied it, the directory of the produced disk is damaged. This happened to me ;)


Martin_Head
Gold Card
Posts: 496
Joined: Tue Dec 17, 2013 1:17 pm

Re: QLiberator decompiler

Postby Martin_Head » Sun Jan 19, 2020 9:50 am

Of course, As soon as I post the user manual for the Decompiler. I start thinking of things I forgot to put in it.

A couple of things when tidying up the decompiled program.

DATA statement lines have a GO TO the next line, at the start of the line. This can be deleted. It's just an internal thing of the compiled program, to make it skip over the DATA statements.

If the original program was compiled without retaining the line numbers. Then the decompiled output may have line numbers greater than the 32000 limit of BASIC. In this case you will need to split the BASIC program in two parts. The first part can be loaded and then renumbered.
The second part will have to be renumbered by hand to follow the first part. Then merged back together again.


Martin_Head
Gold Card
Posts: 496
Joined: Tue Dec 17, 2013 1:17 pm

Re: QLiberator decompiler

Postby Martin_Head » Sun Jan 19, 2020 9:57 am

Ralf R. wrote:
Martin_Head wrote:One zip file is a floppy disk image, and the other, is the files on the floppy image, all zipped up.

It is important to know, that if one wants to put the IMG onto a 720k 3,5" disk with one of the free programs under Windows, the name has to be not more than a few characters, e.g. QLib8.IMG.

If it is as Martin supplied it, the directory of the produced disk is damaged. This happened to me ;)

The image was made with my FDI driver. Without the FDI driver, In QPC2 V4.00 and above it can be mounted by QPC2 itself. I don't know if something went wrong with the windows side.


User avatar
Ralf R.
Gold Card
Posts: 273
Joined: Fri Jun 15, 2018 8:58 pm

Re: QLiberator decompiler

Postby Ralf R. » Sun Jan 19, 2020 9:57 am

Martin_Head wrote:If the original program was compiled without retaining the line numbers. Then the decompiled output may have line numbers greater than the 32000 limit of BASIC. In this case you will need to split the BASIC program in two parts. The first part can be loaded and then renumbered.
The second part will have to be renumbered by hand to follow the first part. Then merged back together again.

That is interesting. The decompiler does not see, if more than one statement was in the original source (because it isn't there any longer) but the error console of QLib has no problem to show the line (albeit with no line number). So, if QLiberator splits all statements in a separate line, there must be another kind of handling the line numbers, in this case, they can be greater than 32767.
Last edited by Ralf R. on Sun Jan 19, 2020 10:02 am, edited 2 times in total.


User avatar
Ralf R.
Gold Card
Posts: 273
Joined: Fri Jun 15, 2018 8:58 pm

Re: QLiberator decompiler

Postby Ralf R. » Sun Jan 19, 2020 9:59 am

Martin_Head wrote:The image was made with my FDI driver. Without the FDI driver, In QPC2 V4.00 and above it can be mounted by QPC2 itself. I don't know if something went wrong with the windows side.

Perhaps it is a fault of the program I used (rawwritewin 0.7) not to detect this or to use the filename as the disk name. Your driver works ok ;) .


Martin_Head
Gold Card
Posts: 496
Joined: Tue Dec 17, 2013 1:17 pm

Re: QLiberator decompiler

Postby Martin_Head » Sun Jan 19, 2020 10:13 am

Ralf R. wrote:
Martin_Head wrote:If the original program was compiled without retaining the line numbers. Then the decompiled output may have line numbers greater than the 32000 limit of BASIC. In this case you will need to split the BASIC program in two parts. The first part can be loaded and then renumbered.
The second part will have to be renumbered by hand to follow the first part. Then merged back together again.

That is interesting. The decompiler does not see, if more than one statement was in the original source but the error console of QLib has no problem to show the line (albeit with no line number). So, if QLiberator splits all statements in a separate line, there must be another kind of handling the line numbers, in this case, they can be greater than 32767.

The compiled SuperBASIC program does not have any kind of markers in the program to show where lines start, or end. So it's just one long line number less program.

If when you compile, you keep the line numbers, then a table is created of the line numbers, and pointers to where the lines start in the compiled SuperBASIC program.
If the line number table exists, then the decompiler uses it to know there lines start and end, and what the decompiled line number should be. So it won't produce line numbers greater then 32000. And you may see multi statement lines.

If the line number table doe's not exist, then the decompiler will produce single statement lines, as it does not know where lines start and end. It also has to 'make up' a line number. This made up line number is comprised of an offset from the start of the program, +100. This can cause line numbers greater then 32000 to be produced if the the compiled program is large.


User avatar
Ralf R.
Gold Card
Posts: 273
Joined: Fri Jun 15, 2018 8:58 pm

Re: QLiberator decompiler

Postby Ralf R. » Sun Jan 19, 2020 10:25 am

Martin_Head wrote:If the line number table doe's not exist, then the decompiler will produce single statement lines, as it does not know where lines start and end. It also has to 'make up' a line number. This made up line number is comprised of an offset from the start of the program, +100. This can cause line numbers greater then 32000 to be produced if the the compiled program is large.

Yes, I understand, but how does the error console handle this, if there were no line number table but multi statement lines? It still shows the statement, which made the error.


Martin_Head
Gold Card
Posts: 496
Joined: Tue Dec 17, 2013 1:17 pm

Re: QLiberator decompiler

Postby Martin_Head » Sun Jan 19, 2020 10:32 am

Ralf R. wrote:
Martin_Head wrote:If the line number table doe's not exist, then the decompiler will produce single statement lines, as it does not know where lines start and end. It also has to 'make up' a line number. This made up line number is comprised of an offset from the start of the program, +100. This can cause line numbers greater then 32000 to be produced if the the compiled program is large.

Yes, I understand, but how does the error console handle this, if there were no line number table but multi statement lines? It still shows the statement, which made the error.

I don't know. So it says something like some error Line 0:3 for an error on statement 3 in the line. I cannot think at the moment of a way that it would know it was on the third statement of a line.


User avatar
Ralf R.
Gold Card
Posts: 273
Joined: Fri Jun 15, 2018 8:58 pm

Re: QLiberator decompiler

Postby Ralf R. » Sun Jan 19, 2020 11:49 am

Perhaps, we will sometimes understand, how QLiberater and its runtimes manages this (if someone disassembles the runtimes and can really understand, how it all works). For me, it would be interesting to know, if there are similarities to SBASIC as the compile times are the same, if QLiberator compiled as an SBASIC program or as an executable under SMSQ/E.


EmmBee
Trump Card
Posts: 158
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: QLiberator decompiler

Postby EmmBee » Sun Jan 19, 2020 1:20 pm

Ralf R. wrote:BTW: The window MOVE takes place in "procfun34401", if someone wants to investigate, "var0388" is true, if PE is available.

Inside procfun34401: IF PE then WM_Sptr and WM_Rptr are both called, else an inkey$ loop is entered where the cursor can be moved around. When ENTER is pressed it comes out the loop and the screen is updated. I have tried this using Q-emuLator with Minerva without the PE present, and this does work. However, it appears to me that a better performance could be obtained by PANning and SCROLLing inside the inkey$ loop. Try adding these lines ...
30875 PAN #var0368, -6
30905 PAN #var0368, 6
30935 SCROLL #var0368, -10
30965 SCROLL #var0368, 10
Now, every time you hit a cursor arrow key QLiberator's front panel will move.



Who is online

Users browsing this forum: No registered users and 6 guests