Wolfgang Lenerz writes:

> > Or a completely different proposal:
>
> (putting the home dir after the command string)

As long as you dont mean that this has to be done on the EX command line, I
agree with the above description.

Having said that, it /would/ perhpas be nice to add something like this as
an option to
overwrite the default home directory, although is does complicate an already
overloaded parameter list:

    EX <filename> ; <command string> ! <different homedir>

> > (...)
>
> > QLib compiled programs pose a challenge as we dont have access to the
> > compiled job's initialisation code to access that information. However,
> > there are other, more plodding, ways to find a job's data area and
locate
> > the HD string. Thus a function such as HOMED$ or CDIR$ to read the HD
string
> > would have to work differently in compiled and interpreted mode.
> >
> > Thereyougo. Now shoot it down in flames!
>
> OK. <Flamethrower mode>
>
>
> I'd thought of that, too. The only problem I see with it is, indeed Qlib.
> I presume that your way of doing it would involve some kind of basic
> keyword that you call and that returns the home dir string.

Precisely

> How do you find this string? Have you tried finding the command string
from a QLibbed
> prog other than with the QLib internal CMD$ command? The problem is that
once you
> get to the stage where your keyword will be invoked, A5 will point to who
knows what
> (in fact, the parameter list, relaive to A6).... I see no safe way to find
the string - but I
> stand to be corrected!

Its first of all a matter of finding the job's dataspace. The Homedir string
is at the top of that, past where the QLiberated job has any legitimate
business to poke around (it thinks its dataspace (according to my scheme) is
48 bytes smaller than it in actual fact is). So QLib initialisation code is
unlikely to scribble over it. (Ive just briefly checked: A QLibbed program
doesnt appear to interfere with its command line either, so thats hopeful.)

I havent looked in detail how the dataspace may be found, but I presume it
possible to find any executing job's dataspace by legitimate means.  It is
also possible that the QLibbed job's a6 points to its dataspace. Either that
or it stores the its location somewhere, as it needs to find its own command
string on demand.

Alternatively, EX could be made to identify a QLibbed program and store its
dataspace address in a known safe location before activation.

This requires investigation, but Im not concerned that it wont be possible.

> </ flamethrower mode>

Better to flame now than once it is implemented ;)

Per

_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to