Page 2 of 18

Re: QLiberator decompiler

Posted: Wed Dec 04, 2019 10:48 pm
by dilwyn
Hi Ralf and Martin,

I've just found an old disk from the 1990s which Ralf sent me, which includes the source for an earlier version of Ralf's "s_edit" editor. This is S-Edit1, the version which runs on pre-GD2 systems.

Doesn't include any linked extension files, but critically includes both compiled and uncompiled versions for you both to compare how the decompiler manages.

Assorted compiled versions, Ralf will confirm which is which I hope, I think the ones with "notk" in the name are without the toolkit 2 extensions subset linked. RUN_obj includes compiler runtimes. the "demo" version IIRC is only able to load files, not save them. Hopefully versions like this with minor variations in code will test the decompiler a small stage further.
sedit58.zip

Re: QLiberator decompiler

Posted: Thu Dec 05, 2019 10:41 am
by Martin_Head
Ralf R. wrote:Hi Martin,

my code looks interesting :), thank you. I have a few GOTOs in my code but not so much as in the recompiled code and just within a few PROCs. Seems I had better compiled with VARs ON to get a proper nametable for recompiling.

Seems, you had to add a BP.INIT to my(!) inbuilt extensions, as there weren't any.

Thank you!
I suspect that some of the GO TO's are to do with REPeat loops. REPeat loops are converted into GO TO's along with the NEXT and EXIT's .If you see a variable assignment like 'var0080=0', and var0080 does not seem to be used again. Then it's likely, the start of a REPeat loop. I have sorted as many of these REPeat loops that I have seen, But there were some that did not look quite right to be REPeat loops. It's possible the decompiler has got confused, I need to look into it further. In the compiled programs, the code used for GO TO is used extensively, And it can be difficult to decide what is and isn't a real GO TO.

After the posting I noticed another problem is sedit that I need to look into. It looks like there was a SELect line in a group of SELects, with no statements in it. Just 'ON var=something:', then followed by the next 'ON var=something:'. This seems to have confused the decompiler into thinking that another SELect had started, and I ended up with two END SELects instead of one.

As for the BP.INIT, There seems to be 2 or 3 ways to add extensions in QLiberator, Some seem to be called Externals, I think. They are stored in a linked list, and some have a normal BP.INIT code at the start, and some do not. But they have a normal table of procedure and function definitions. So I just added the needed BP.INIT code. The last one, I think it's 'Easy menu'? Needed subroutine calling as well as the BP.INIT. Sedit is the only program so far that I have extracted routines from, So I don't know if I have got it all correct.

I have downloaded the code from Dilwyn, And I will have a look at it.

Re: QLiberator decompiler

Posted: Thu Dec 05, 2019 12:12 pm
by RalfR
Martin_Head wrote:I have downloaded the code from Dilwyn, And I will have a look at it.
The MC extensions from me are all without any BP.INIT, as this isn't necessary for QLib. it was just a kind of protection scheme in these days. QLib_ext and Easyext have them of course, as these extensions are used untouched.

If you may look in the source, Dilwyn has sent, it is better to use this compiled version of S_Edit for better comparing.

Re: QLiberator decompiler

Posted: Fri Dec 06, 2019 12:13 pm
by BSJR
Martin_Head wrote: I suspect that some of the GO TO's are to do with REPeat loops. REPeat loops are converted into GO TO's along with the NEXT and EXIT's .If you see a variable assignment like 'var0080=0', and var0080 does not seem to be used again. Then it's likely, the start of a REPeat loop.
Although a REPeat var is flagged differently in the name table (0602), it's perfectly legal to use it to store a value while within the loop and something I also sometimes do.
In SMSQ it's even possible to leave the var out but that's not my preferred practice. I don't even know if Qlib supports this behaviour.
Martin_Head wrote: After the posting I noticed another problem is sedit that I need to look into. It looks like there was a SELect line in a group of SELects, with no statements in it. Just 'ON var=something:', then followed by the next 'ON var=something:'. This seems to have confused the decompiler into thinking that another SELect had started, and I ended up with two END SELects instead of one.
This empty SELect is also a valid technique that I often use.
: SELect ON mode
: = 0,1,4,8,16,32,33 :
: = REMAINDER : Report_ModeError
: END SELect
This will filter out only valid modes and is shorter than using IF statements.

BSJR

Re: QLiberator decompiler

Posted: Fri Dec 06, 2019 2:17 pm
by RalfR
I always used it that way.
BSJR wrote:This empty SELect is also a valid technique that I often use.
: SELect ON mode
: = 0,1,4,8,16,32,33 :
: = REMAINDER : Report_ModeError
: END SELect
This will filter out only valid modes and is shorter than using IF statements.

BSJR

Re: QLiberator decompiler

Posted: Mon Dec 09, 2019 10:48 am
by Martin_Head
Martin_Head wrote:Some the procedure calls have picked up the wrong names for the Procedure definitions e.g. a call to ProcFun10891 should be ProcFun10890
I think I have sorted this problem out now. Four Procedure names need changing.

Lines 6910 & 7130, Change procfun10890 to procfun10891.
Lines 13800 & 13890, Change procfun22160 to procfun22161.
Lines 20730 & 21240, Change procfun35118 to procfun35119.
Lines 26420 & 26540, Change procfun45318 to procfun45319.

The empty SELect line should also be sorted out now.

I would like to try to get Disk Mate 5 into a LOADable state now. I also need to look into WHEN ERROR handling.

Re: QLiberator decompiler

Posted: Mon Dec 09, 2019 1:50 pm
by RalfR
Martin_Head wrote:I also need to look into WHEN ERROR handling.
For that, you have to compile with QLib 3.36, because it is only supported there.

Re: QLiberator decompiler

Posted: Tue Dec 10, 2019 9:54 am
by Martin_Head
I had a quick look at decompiling QLiberator itself yesterday. There appears to be two compiled programs, QLib_obj and QLib_Patch_obj. The Patch file ran through the decompiler with a couple of warnings, But the QLib file threw up several warnings, and hit an unrecognised code. It also looks like it uses some ON ... GO TO's which the decompiler did not handle as well as I expected.

Re: QLiberator decompiler

Posted: Wed Dec 11, 2019 6:55 pm
by RalfR
Martin_Head wrote:I had a quick look at decompiling QLiberator itself yesterday. There appears to be two compiled programs, QLib_obj and QLib_Patch_obj. The Patch file ran through the decompiler with a couple of warnings, But the QLib file threw up several warnings, and hit an unrecognised code. It also looks like it uses some ON ... GO TO's which the decompiler did not handle as well as I expected.
Oha, they should have known better with ON...GOTO. I hope, they haven't put machine code inside their code (what you perhaps have imagined)...

Re: QLiberator decompiler

Posted: Sat Dec 14, 2019 10:45 am
by Martin_Head
Ralf R. wrote:Oha, they should have known better with ON...GOTO. I hope, they haven't put machine code inside their code (what you perhaps have imagined)...
I've done a bit of rewriting of my ON..GO TO/SUB handling, and I also had to add handling of READ into an array element.

I have now got a decompile of QLIB_OBJ that I am looking through for problems, and tidying up ready for loading. There are some embedded SuperBASIC extensions, which I have extracted, but not looked at yet.

I am also going through Disk Mate 5, doing the same. But it's a big program, and there are a lot of REPeat loops and SELects that need tidying. I am trying to convert as many GO TO's into END REPeats, NEXTs, and EXITS as I can.

Another thing I need to do, is to get some some more documentation done. Then I might be able to post the current decompiler here.