Dilwyn Jones wrote:
Contrary to Per's comments, I am most grateful to the many people who
<>
I had a look at John's boot program but lack of time prevents me from
taking a very detailed look.
Basically, his program revolves around code like:
<>
Sounds like the real problem here is one of complexity ;o)
As others have already commented, all but the simplest boot files
should be split into at least two files. One for loading the core
components and another (or a choice of others) for the rest.
(I use a third tier for the most dynamic components, such as default
directory or win_drive selection. This is easily accessible from my
Qascade "Start Menu" to pop straight up in an editor.)
One of the problems is communicating between any secondary boot files
and the primary one. This seems to be one of the issues here. There
are many ways around it, and John's way of dumping EXTRAS to a file
and parsing that file is valid, although perhaps somewhat slow and
cumbersome.
A quicker method might be for the primary boot file to create a status
file on the fly and the secondaries to parse that instead. It should
be a lot more concise and therefore quicker.
However, there are a lot of toolkits that provide a way of checking
whether keywords have been loaded, including my FINDNAME_BIN (258
bytes). Such a toolkit could be loaded by the primary, and the
secondary boot script would use something like
IF FINDNAME%("Q_L"): DO_THIS: ELSE: DO_THAT
(This works the same in daughter SBasics as in job#0, BTW)
The problem with boot files is that they tend to grow and evolve, and
as so much depends on these increasingly tweaked and convoluted
creations, one finds it hard to tidy them up or start again from
scratch. If you spend more than an hour or so trying to debug one, it
is perhaps time to start afresh!
Per
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
