Marcel Kilgus writes:
> No, I have for example a "current directory" in mind, which should be
> changeable (on request of the application) after the application
> started to run. I also have a device in mind that automatically
> accesses the "current directory". None of which is cleanly doable with
> the "put it into data space" method. As soon as a job runs the data
> space is his to mess with, nobody else. How should a potential device
> find the directory name there?
Fair enough, but you are trying to solve a different problem to the one I
was solving. Im not a mind reader.
I never knew that I wanted a current directroy, but I can see that it makes
sense. However, this is a much more ambitious project than a mere home
directory affair. You have to alter the device driver to cater for it too.
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.
There is nothing wrong with that per se, as long as we are concious of the
fork in the road. My proposal would have allowed retro-fitting onto Qdos,
either as a separate toolkit to replace EX & co, or by upgrading the file
version of TK2 should the sources ever become available.
> And, thinking further, the thing could even do more. It could supply
> the complete filename of the EXE, it could supply the path of the EXE
This has been my thinking all along, too.
> ("home directory") AND it could supply a "current directory". All with
> very little effort. Then it could offer services like "change
> directory", a bit like DUP and DDOWN. A third party (like the
> mentioned device) could easily get the directory for another job,
> without any guessing. All neat and clean.
Very nice ;)
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.
Equivalent functionality to DUP and DDOWN could be a system service and be
applied to that string. The assembler programmer would have some assistance
to maintain this file name string, but it wouldnt be a true Current
directory. For the Sbasic programmer the illusion of a true Current dir
could be made total, so he wouldnt be able to tell the difference between
your Current dir solution and mine.
> 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.
> > 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).
>
> 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.
> > 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.
>
> That's why an independent interface like a thing could really help. It
> can be accessed from any language because it does not rely on any
> information but the job-ID, which is always readily available.
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 ;)
Per
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
