Problem loading extensions

[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

[Giorgio Garabello]

On SMSQmulator:

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

Giorgio

[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.

[stevepoole]

Hi,
Try putting a PAUSE 300: after each lrespr ?
Steve Poole.

[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

[Giorgio Garabello]

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.

[Giorgio Garabello]

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?

[Giorgio Garabello]

Hi,
Try putting a PAUSE 300: after each lrespr ?
Steve Poole.

Done
the result don't change. :-/

[RWAP]

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)

[janbredenbeek]

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.