Marcel Kilgus writes: <> > > However, this is a much more ambitious project than a mere home > > directory affair. > > Actually I think it doesn't amount to much more work.
Perhaps it is a separate piece of work altogether? Afterall, why not have as many current directories as you like, from 0..n? This could be a separate System Service altogether. > > You have to alter the device driver to cater for it too. > > Hm, which? I don't propose that every device driver should know about > the current directory but that there could be a new device like > "home_" or something that did specifically include the current-path, > exe-path or whatever. You did mention OPEN in an earlier mail... > > It also implies that Qdos is left out in the cold and that > > programmers who want to make their programs run under Qdos will have > > to make a considerable effort to achieve that. > > Hmm, why? Currently I don't see anything in my proposal that is > strictly SMSQ/E specific. > Thought I am beginning to hate QDOS compatibility, just out of spite. As above. Another thing with Things is that every program will have to carry the code to scan for the THING Thing (apologies to the scores of avid readers following this thread for this apparent mumbo-jumbo ;) if they want to stay Qdos compatible. Not a big deal but the word "bloat" does tend to insinuate itself.. > > However, my thinking goes: If all the Homedir is wanted for is to find > > the location of some config file (as will often be the case) then the > > space taken up by the Homedir string could simply be re-used as a > > Current dir. > > Well, this is what I call a "hack". Nothing wrong with that per se, I > do that a lot. But if I design a *new* OS interface it is usually not > the way I want to go, at least if I can't help it. <> No, extending the CDB was a hack, and not a pretty one either, but quite servicable. My proposal is an extension of an existing facility, namely stacking an additional parameter above the command line, where only cognizant programs will know to look for it. The concept is widely used throughout Qdos/SMSQE. The only hack involved would be to get QLib to find it, and QLib is going to have to be hacked almost whatever solution is chosen. > >> I don't see memory fragmentation as a problem. The memory block will > >> start its life with the memory block for the job and will end its life > >> along with it. No fragmentation really. > > If you say so. You havent explained how you would set about it. > > Example: allocate the memory before the execution of the job with the > job as the owner. It will get freed automatically on removal of the > job. And how do you know that the memory is not valid anymore? Easy, > the job-ID won't be valid anymore. The fragmentation I suggested would be due to the fact that whenever a job dies there will be three holes in memory instead of just two. However, I concede that this probably is insignificant. Per _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
