The FEX that DiskMate expects is a procedure. The FEX that is now part of SMSQ/E is a function. Q_ERR_ON only works with procedures... as tofro said, name clash.Martin_Head wrote:tofro wrote:If I run the compiled Diskmate 5 in QPC2, it stops with an error on Q_ERR_ON, which I assume is this line. You can then 'C'ontinue to get past it. So I thought it was an issue with Q_ERR_ON in one of the QLiberator extensions.
QLiberator decompiler
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: QLiberator decompiler
Re: QLiberator decompiler
From the FileInfo 2 Manual:
Tobias
So - Simply replace "FEX" with "FI2_CALL" in the DiskMate source code and you should be set, and DiskMate should be working with newer SMSQ/E versions.The FEX procedure is the exact equivalent of FI2_CALL and FEX_W is equivalent to
FI2_CALL with the bit 31 of the key set. FEX and FEX_W are kept for upward
compatibility with older FileInfo things only; these procedures should not be
used any more in modern programs as their name clashes with SMSQ/E v3+ built-in
PROC/FN. By default, FileInfo II v3.50+ is configured so to skip the
initialization of the FEX and FEX_W procedures.
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: QLiberator decompiler
I doubt this will work. DM5 expects the name FEX and will not react to FI2_CALL.tofro wrote:From the FileInfo 2 Manual:
So - Simply replace "FEX" with "FI2_CALL" in the DiskMate source code and you should be set, and DiskMate should be working with newer SMSQ/E versions.The FEX procedure is the exact equivalent of FI2_CALL and FEX_W is equivalent to
FI2_CALL with the bit 31 of the key set. FEX and FEX_W are kept for upward
compatibility with older FileInfo things only; these procedures should not be
used any more in modern programs as their name clashes with SMSQ/E v3+ built-in
PROC/FN. By default, FileInfo II v3.50+ is configured so to skip the
initialization of the FEX and FEX_W procedures.
Tobias
For that DM5 will need to be edited and recompiled.
I have changed the name FEX to FFX in both my copies of FI2 and DM5 and configured FI2 to use both names.
Now DM5 will not complain.
BSJR
Re: QLiberator decompiler
Of course it will - maybe there's a slight misunderstanding. Replacing that single occurrence is obviously not enough, rather all occurrences of FEX in DM5 need to be replaced. I thought that was clear. Then this will end up to be the same solution as yours, just without changing FI2 as well.BSJR wrote:I doubt this will work. DM5 expects the name FEX and will not react to FI2_CALL.tofro wrote:F
So - Simply replace "FEX" with "FI2_CALL" in the DiskMate source code and you should be set, and DiskMate should be working with newer SMSQ/E versions.
Tobias
For that DM5 will need to be edited and recompiled.
I have changed the name FEX to FFX in both my copies of FI2 and DM5 and configured FI2 to use both names.
Now DM5 will not complain.
BSJR
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Aurora
- Posts: 854
- Joined: Tue Dec 17, 2013 1:17 pm
Re: QLiberator decompiler
Yesterday I tried to get the decompiled QLiberator to compile itself. I wondered, that if I got the right compile options, I could maybe make an exact copy the the original QLIB_OBJ. That way I would know that the decompile was accurate.
Didn't go quite to plan. It would not compile itself. It got so far, then BASIC threw up an error message. So I am now bug hunting for either a decompiler problem, or if I have made a typo somewhere while tidying up the program code.
Didn't go quite to plan. It would not compile itself. It got so far, then BASIC threw up an error message. So I am now bug hunting for either a decompiler problem, or if I have made a typo somewhere while tidying up the program code.
Re: QLiberator decompiler
Im sure you dont need any advice from me Even so, since I use this program quite a lot, I venture some suggestions in case you hadnt got round to them yet: Try compiling with the already compiled QLib. For debugging purposes switch on Names, Lines, and Stats (The final version will probably have all these switched off). Try compiling from Qdos rather than SMSQ/E. DP's Xref program can be useful for finding bugs and inconsistencies. The Turbo parser can also be useful when all else fails (ie try compiling it with Turbo just for its analysis)..
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: QLiberator decompiler
I've attached my "once" program. What it can do is to identify any names used once only - which could be misspellings. It has to be run in QPC2 as it uses the functions DEVTYPE, SCR_XLIM and SCR_YLIM, which are only available in SMS. I hope this helps. Best of luck.
-
- Aurora
- Posts: 854
- Joined: Tue Dec 17, 2013 1:17 pm
Re: QLiberator decompiler
A bit of an update.
The BASIC error was caused by a typo on my part, rather than a problem with the decompile. That got the compile to work.
The next problem, was that when I EXEC the resulting object I got a Qliberator error, something about an undefined variable. That turned out to be CMD$. I had to identify the variable in the source code, and rename it CMD$.
Next, When I EXECed the the program (The one that compiled itself, and one compiled with the original QLiberator) I could not select any of the input boxes, or buttons. This turned out to be because I had the WINDS selected during compile, which seems to stop the pointer interface bits working.
At the moment, I think the recompiled QLIB is maybe 10 bytes shorter that the original, The dataspace maybe 32 bytes bigger. If I use QLIB_PATCH, it reports the number of channels as 10, when it should be 9. When you use a compiler directive of $$chan= Should it be 1 less than the number you want, to allow for channel 0?
There is one other odd thing I have noticed when comparing the original QLIB with my recompiled one's. There is a bit of data stored between the end of name list, and the start of the name/variable table
This is the start of the program, note the something odd???
And this is the something odd. Any one recognize what it may be, and how to incorporate into the compile
The BASIC error was caused by a typo on my part, rather than a problem with the decompile. That got the compile to work.
The next problem, was that when I EXEC the resulting object I got a Qliberator error, something about an undefined variable. That turned out to be CMD$. I had to identify the variable in the source code, and rename it CMD$.
Next, When I EXECed the the program (The one that compiled itself, and one compiled with the original QLiberator) I could not select any of the input boxes, or buttons. This turned out to be because I had the WINDS selected during compile, which seems to stop the pointer interface bits working.
At the moment, I think the recompiled QLIB is maybe 10 bytes shorter that the original, The dataspace maybe 32 bytes bigger. If I use QLIB_PATCH, it reports the number of channels as 10, when it should be 9. When you use a compiler directive of $$chan= Should it be 1 less than the number you want, to allow for channel 0?
There is one other odd thing I have noticed when comparing the original QLIB with my recompiled one's. There is a bit of data stored between the end of name list, and the start of the name/variable table
This is the start of the program, note the something odd???
Code: Select all
00282A70 60000082 bra $00282AF4 `...
00282A74 00004AFB ori.b #$FB,d0 ..J.
00282A78 0009 ILLEGAL INSTRUCTION ..
00282A7A 516C6962 subq.w #$08,$6962(a4) Qlib
00282A7E 5F332E33 subq.b #$07,$33(a3,d2.l) _3.3
00282A82 3620 6
00282A84 2020
00282A86 2020
00282A88 2020
00282A8A 2020
00282A8C 2020
00282A8E 2020
00282A90 00000146 start of SuperBASIC program 282BB6
00282A94 0000B18C name/variable table 28DBFC
00282A98 00000000 line number table - none
00282A9C 00040000
00282AA0 736E
00282AA2 0009 channels 9
0080 buffer? 128
02000000
00282AAA 1B58 heap size 7000
0394
00282AAE 0330
00282AB0 0000AECA name list 28D93A
00282AB4 00009630 start of extensions 28C0A0
00282AB8 00004FA2 dataspace? 20386
00282ABC 0000157C stack? 5500
00282AC0 0001
0000B16C something odd??? 28DBDC
0001
00282AC8 FF00
00282ACA 00000000 ori.b #$00,d0 ....
00282ACE 00000000 ori.b #$00,d0 ....
Code: Select all
0028DBD4 065F4845 addi.w #$4845,(a7)+ ._HE
0028DBD8 4C50 ILLEGAL INSTRUCTION LP
0028DBDA 4600 not.b d0 F.
end of name list
something odd
0028DBDC 00000000 ori.b #$00,d0 ....
0028DBE0 00020010 ori.b #$10,d2 ....
0028DBE4 04 514C494200 "QLIB"
0028DBEA 00000000 ori.b #$00,d0 ....
0028DBEE 00004E71 ori.b #$71,d0 ..Nq
0028DBF2 283C0000000C move.l #$0000000C,d4 (<....
0028DBF8 6000FD36 bra $0028D930 `..6
name/variable table
0028DBFC 0318 btst d1,(a0)+ ..
0028DBFE 00001800 ori.b #$00,d0 ....
0028DC02 0618000B addi.b #$0B,(a0)+ ....
0028DC06 1800 move.b d0,d4 ..
0028DC08 1118 move.b (a0)+,-(a0) ..
0028DC0A 00181800 ori.b #$00,(a0)+ ....
0028DC0E 1F18 move.b (a0)+,-(a7) ..
0028DC10 00231800 ori.b #$00,-(a3) .#..
Re: QLiberator decompiler
The manual says: "The minimum size of a channel table is 3 entries, for channels 0, 1 and 2" - so its the actual number of channels that need to be given.
CMD$ is initially set up by QLiberator as a variable to read the incoming Option command string and can be used as a normal variable afterwards.
Sounds like you're making excellent progress. Are you compiling with QDOS or SMSQ/E?
CMD$ is initially set up by QLiberator as a variable to read the incoming Option command string and can be used as a normal variable afterwards.
Sounds like you're making excellent progress. Are you compiling with QDOS or SMSQ/E?
Re: QLiberator decompiler
I had a bit of a fiddle, but no joy. Sorry.Martin_Head wrote:This is the start of the program, note the something odd???
Fantastic progress, though!
Per
dont be happy. worry
- ?
dont be happy. worry
- ?