"BOOT" - Choose the Operating System required and load same. (QDOS
OR SMSQ) [if QDOS is selected then do nothing since QDOS is the
native OS whereas if SMSQ is selected, LRESPR SMSQ_GOLD) - LRUN
BOOT2
I should perhaps have qualified this - one boot can both install SMSQ
and install the toolkits/extensions:
100 IF VER$<>"HBA" THEN
110 REM only offer to install SMSQE if not already present
120 INPUT"1=SMSQE 2=QDOS";os
130 IF os = "2" THEN LRESPR WIN1_EXTNS_SMSQ_REXT
140 END IF
150 REM now install every other toolkit
160 IF VER$ <> "HBA" THEN
170 TK2_EXT : REM ensure TK2 enabled on QDOS systems
180 REMark install pointer environment on QDOS
190 LRESPR win1_extns_ptr_gen : REM in this order...
200 LRESPR win1_extns_wman
210 LRESPR win1_extns_hot_rext
220 END IF
230 LRESPR this....
240 LRESPR that....
(and so on)
500 REM define hotkeys
(and so on)
800 REMark activate hotkeys job
810 HOT_GO
There's no problem with combining different actions in a boot program
as long as it's fairly inline code and easy to follow - I tend to try
to avoid calls to procs and functions in my boot programs. Equally,
there's nothing to prevent you splitting it into 3 or 4 programs if it
makes it easier for you to work out what's going wrong when you get
problems like the ones you have with this program.
Queries:- on my QLs (Aurora, SGC, QuBide, etc.) TK2 is loaded
automatically at power-on (AUTOTK2F1 command), the file "BOOT" is
located, LOADed and runs automatically. Are the "EXTRAS" within TK2
LRESPRd in the same manner as if TK2 were LRESPRd from either the
command line or from within a boot program? OR are they 'loaded'
some other way which may cause some or all of them to go missing?
No, this is a full TK2 implementation, built into Super Gold Card. The
AUTOTK2F1 just simply means you do not need a TK2_EXT statement in
your boot program. Even if you use both, it won't do any harm -
TK2_EXT just "enforces" the defintiions. They are installed just as if
you had LRESPRed a disk based copy of toolkit 2. Even though it's
built into Super Gold Card it should be listed by EXTRAS as normal.
LRESPR SMSQ_GOLD causes the machine to RESET following
which it initialises again. Does this RESET remove TK2 from memory
and is TK2 then automatically reloaded again? File "BOOT" is then
run again and only LRUNs "BOOT2" (since AFAIK there is no way of
changing from SMSQ to QDOS without manually RESETing the machine).
Since it obviously takes some time to activate TK2 (automatically
or otherwise) would it be quicker to load TK2 along with all the
other required extension (in "BOOT2") provided no TK2 "EXTRAS" are
required before then?
In this case the Super Gold Card toolkit 2 disappears and SMSQ/E takes
over the machine. SMSQ/E has its own Toolkit 2 extensions built in, so
you won't need to find a way of reinstalling the toolkit 2 extensions
or load it from disk - in fact it's better not to try this in case any
of the old "QDOS" toolkit 2 extensions work a little differently to
SMSQ/E toolkit 2 extensions in any way. Just accept that once you are
in SMSQ/E (all versions) you automatically have toolkit 2.
When a SB program is EXECd (from SMSQ) I have noticed that it
too becomes resident in the same way as an LRUN SB program. Does
this mean that the EXECd program also becomes Job0?
Umm, not quite sure what you mean here. Generally, if you EXEC a
SBASIC program in SMSQ/E systems, it usually becomes a SEPARATE basic
job, i.e. might be Job 1, Job 2, etc (if you list the running job with
the JOBS command you'll see more than one basic program, usually job 0
has no name, while the second, third etc might have the names SBASIC -
showing that you now have two instances of BASIC running. After
entering the JOBS command:
Job Tag Owner Priority Job-Name
0 0 0 32
1 1 0 s127 HOTKEY
2 2 0 s8 SBASIC
Job 0 is always the one available when SMSQ/E starts. This cannot be
removed manually (unless you seriously crash it in which case it
probably takes the whole of smsq/e with it, a Dilwyn-style programming
crash!!!)
Be a little bit careful about assuming that executed basic programs
will always start a new job. It depends how you go about it. On my
system I use fileinfo 2 and executing an sbasic program from disk with
the QPAC2 Files menu will simply cause it to be executed in the main
Job0, hence the possible source of confusion. Executing them with an
EXEC or EX command from the basic job0 command line will create aa new
sbasic job. Executing them with Qpac2 FIles menu, Launchpad basic
launcher etc is not so easy, it depends on the setup on that system.
If you want to be sure (and it will help show what happens) issue an
SBASIC command first to start a new sbasic daughter job and LOAD or
EXEC the program from there. At this point it starts to get a little
confusing, I know. Basically, LOAD or QLOAD will start the program in
the same job. EXEC or EX might create a new job.
Can anyone see why this sequence of programs {which I am
confident will run on both QDOS and SMSQ on the Auroras} should not
run exactly the same under QPC2 on my Vista PCs? (which is the
original point I raised with my existing programs).
Not really. All you can do is trial and error - remove one set of
extensions at a time to see if removing one cures the problem, and
test for individual extensions one at a time until you find the one
which causes the problem. Time consuming, but the only way you'll pin
it down.
After the discussion on EXTRAS, Marcel explained that although a
little problem with EXTRAS had been fixed for an older version of
SMSQ/E, it is working fine now as long as you remember that if you
LRESPR extensions in a separate daughter job (Job number not zero in a
JOBS list, e.g. Job number 2), only the daughter job will know about
those (in this case, as Job 2 loaded it, only Job 2 sees it - the
SBASIC manual calls them LOCAL to one particular job). But if you
LRESPR them into Job0, then ALL daughter jobs should be able to see
the extensions. There is one little proviso for this. LRESPR can't be
used to install system-wide extensions from any job other than job 0 -
the SBASIC manual cites menu_rext and QTYP as examples. But if
extensions are loaded from Job 0 there's no issues like this, all jobs
should eb able to see them in their EXTRAS list.
The only way I can see extensions disappearing like the problem you
are having is:
(1) a rogue extension (can only be established by the one step at a
time trial and error described above to isolate the particular one)
(2) LRESPR used on SOME systems where a job other than job 0 is
already running - where the particular version of LRESPR tries to use
the equivalent of ALCHP instead of the equivalent of RESPR. If so, a
subsequent LOAD or NEW or whatever might make the extension disappear
as it was in the common heap memory instead of in the RESPR area where
it belongs. Extremely unlikely on modern systems, LRESPR usually gives
a 'Not complete' error if another job is running.
(3) If you use RESPR/LBYTES/CALL instead of LRESPR, the number of
bytes given to RESPR has to be at least as long as the extension,
otherwise the next RESPR might overwrite part of the previous thing
you LBYTEd. Usually only happens when extensions get updated by the
author and change length and you forget to change the RESPR statement.
Did you try changing the extension checked for from "Q_L" to something
else to see if all extensions are affected or does it just happen to
be that particular QLiberator one?
Dilwyn Jones
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
