Marcel Kilgus writes: <> > If the job "uses" the thing, the thing is informed when the job dies. > Even if not, one could allocate the necessary memory on behalf of the > job and therefore it would get freed along with the job. > > So far I think I'd prefer that over any stack hack, but I haven't > completely made up my mind yet.
Theres no stack hack involved; simply a new convention. I suspect you may have the path depth/filename length issue at the back of your mind. So did I. Ideally, setting up the stack in this way should be done via a single system call (a "System Service" call in my parlance), accessable to any program or toolkit that is in the business of EXecuting jobs for whatever reason. That way, if at some time in the future the 36 char limit were to be removed, there would only be a single routine to change. M/c programs wanting to set up sub-jobs for it own purposes could still do so manually in the old way, ignoring the new convention if it doesnt need HDs. My proposal is less likely to fragment memory and would use less of it (M/c programs could simply use the memory reserved for the HD if it were not required). Whatever the low-down implementation, ideally the workings of the HD/CD should be as consistent as possible accross m/c programs, interpreted Sbasic or compiled Sbasic. Per _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
