Page 1 of 2

Problem loading extensions

Posted: Sun Feb 19, 2017 9:48 pm
by Giorgio Garabello
HI, on QPC2 I wrote a small test program, in which load the names of several extensions in a table and then load (LRESPR) scanning the table.

Code: Select all

100 WTV
110 LAUNCH
120 DEFine PROCedure LAUNCH
130    DIM TAB_EXT$(3,50)
140    TAB_EXT$(0) = "WIN1_CLAVIER_bin"
150    TAB_EXT$(1) = "WIN1_DBAS_sys"
160    TAB_EXT$(2) = "WIN1_ENV_bin"
170    TAB_EXT$(3) = "WIN1_FILEINFO2_bin"
180    :
190    FOR I = 0 TO 3
200       LRESPR TAB_EXT$(I)
210    END FOR I
220    :
230 END DEFine LAUNCH
If I try to load an extension in the usual way (LRESPR filename) and then load the other using the table QPC2 crash

Code: Select all

100 WTV
105 LRESPR WIN1_DBAS_sys
110 LAUNCH
120 DEFine PROCedure LAUNCH
130    DIM TAB_EXT$(2,50)
140    TAB_EXT$(0) = "WIN1_CLAVIER_bin"
150    TAB_EXT$(1) = "WIN1_DBAS_sys"
170    TAB_EXT$(2) = "WIN1_FILEINFO2_bin"
180    :
190    FOR I = 0 TO 2
200       LRESPR TAB_EXT$(I)
210    END FOR I
220    :
230 END DEFine LAUNCH
This happens with any extension.
Any idea to solve the problem?

Giorgio

Re: Problem loading extensions

Posted: Sun Feb 19, 2017 10:07 pm
by Giorgio Garabello
On SMSQmulator:

the first example work correctly as on QPC2
the second example reset SMSQMulator.

Giorgio

Re: Problem loading extensions

Posted: Sun Feb 19, 2017 11:00 pm
by janbredenbeek
I'm not sure if it's OK to load extensions within a S*BASIC procedure since this modifies the Name Table, which is also used to store parameters and LOCal variables. Try loading the extensions outside a procedure.

Jan.

Re: Problem loading extensions

Posted: Sun Feb 19, 2017 11:55 pm
by stevepoole
Hi,
Try putting a PAUSE 300: after each lrespr ?
Steve Poole.

Re: Problem loading extensions

Posted: Mon Feb 20, 2017 5:54 am
by swensont
In the second example, you are loading DBAS_sys twice. Could that be the issue? Remove it from the procedure and see if it works.

Tim Swenson

Re: Problem loading extensions

Posted: Mon Feb 20, 2017 7:52 am
by Giorgio Garabello
swensont wrote:In the second example, you are loading DBAS_sys twice. Could that be the issue? Remove it from the procedure and see if it works.

Tim Swenson
changing extensions the problem remain the same.

Re: Problem loading extensions

Posted: Mon Feb 20, 2017 8:15 am
by Giorgio Garabello
janbredenbeek wrote:I'm not sure if it's OK to load extensions within a S*BASIC procedure since this modifies the Name Table, which is also used to store parameters and LOCal variables. Try loading the extensions outside a procedure.

Jan.
mmmmmmmmmmmmmmmm......
so, is better to launch extensions as soon as possible in the boot?

Re: Problem loading extensions

Posted: Mon Feb 20, 2017 9:49 am
by Giorgio Garabello
stevepoole wrote:Hi,
Try putting a PAUSE 300: after each lrespr ?
Steve Poole.
Done
the result don't change. :-/

Re: Problem loading extensions

Posted: Mon Feb 20, 2017 11:23 am
by RWAP
Giorgio Garabello wrote:
janbredenbeek wrote:I'm not sure if it's OK to load extensions within a S*BASIC procedure since this modifies the Name Table, which is also used to store parameters and LOCal variables. Try loading the extensions outside a procedure.

Jan.
mmmmmmmmmmmmmmmm......
so, is better to launch extensions as soon as possible in the boot?
I agree - the problem is probably because the LRESPR command is used inside the procedure after an initial LRESPR outside of the procedure - it has probably caused name table corruption of some sort because it means a SuperBASIC procedure name will appear in the midst of machine code extension names (although this should not make a difference)

Re: Problem loading extensions

Posted: Mon Feb 20, 2017 4:18 pm
by janbredenbeek
Giorgio Garabello wrote: so, is better to launch extensions as soon as possible in the boot?
Yes. When you call a SB procedure or function, the name table gets extended by the parameters and LOCAL variables in the procedure. These entries are removed after you return from the procedure. Now when you load extensions, there are also new entries in the NT created (usually at the top). I'm not sure if they will be preserved by the cleanup that SB does after returning from the procedure. It's best to load them at the start of the boot program.
There is also a difference in the way the ROM versions treat extensions with conflicting names. On AH and JM they simply get appended to the NT without checking, so they won't override the existing entry unless you fix the NT yourself after loading (which TK2 does, e.g. after TK2_EXT). This is also why you cannot use your extensions in the same BOOT file that loads them, since the entries have already been created by the time they get LRESPR'd. On JS and later this is no problem since they check the new extension names against the existing names and override these when they are the same.

Jan.