P Witte wrote: > I never knew that I wanted a current directroy, I didn't know that you want one either, but I know that *I* would like one ;-)
> 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. > 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. > 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. > 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. The new colours for WMAN are sort of a hack, too, though I tried to design them as well as I could, but there the structures were already given, so not much choice. Actually the whole PE was and is a hack, albeit a very good one, so it fits right in ;-) >> And how do you know the OS does provide all those "directory" >> services? Easy, if it didn't, there would be no thing! Can't say the >> same about (A6,D3.L) or something similar. > That was a simple suggestion to carry a more complex argument; not a > solution, the best solution, the only solution or the whole solution. No offence meant, just wanted to give an example. The question is always "how do I know I'm running on a system that provides the service I want". >> 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. Other thought: make the job use the thing, which in turn reserves the memory. On removal the thing will be informed and can deal with that. Just a thought, I am NO expert on things. > Your idea sounds excellent. Instead of my bicycle you and Wolfgang have > produced a Mercedes. I am in favour (as long as I dont have to produce it ;) Damn, that was my precondition, too! ;-) But it does start to sound like a worthwhile job. Marcel _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
