Wolfgang Lenerz writes: <> > > 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> > > Before IMPROVING the service, let's already get it... > (grin) > (...)
Of course. But its good to peek around the corner - as we are doing - to see how it might affect the implementation. > > Its first of all a matter of finding the job's dataspace. > > No,no! > > To recap: <> > command line (a6,a5) This is not the case. As it says in the documentation (and I have just varified it with Jmon) (a6,a5) points to the top of the data area (it says "points to the top of the jobs area" but this is a typo). It doesnt point to the command string (although the illustration seems to suggest that). (Qdos Bible, Section 3.0 pp 1-2) The top part of the data area is of course the stack. The language is perhaps a bit imprecise - at least to mere mortals like myself: When you set up a job "manually" from m/c you specify exactly how big the data area must be. That will include the amount of dataspace you require plus the size of stack you need. When EX sets up the job for you it uses the dataspace specified in the file header, but then adds at least one word (channel count), plus room for the actual number of channel IDs, plus enough space to contain the command string, if any, on top of that again. As the size of this cannot be known at compile time (its entirely up to the user, not the programmer) this has to be in addition to the fixed dataspace size you specified. Since all this is a single, contiguous block of memeory, consisting of the job's private data, it can justifiably be called the data area. Since EX already uses this technique to add the user-specified data on top of the (programmer-specified) dataspace, it didnt seem unreasonable to me to extend the concept to include the home directory string. As it happens, (a6,a5) would then point to the magic marker I suggested in a previous mail - or into the void where, as I mentioned, QLib had no business to poke around. QLib does, of course, know about the space taken up by the channels and command string and so, if it likes, can scribble all over it. It cant scribble over "my" area as, as far as it is concerned, that memory doesnt belong to it. I hope this clarifies matters. However, the point is moot at present, since it seems that at a different solution is currently the favourite. <> Per _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
