Wolfgang Lenerz wrote: --->> Finally, progs executed from memory (executable things) would > probably not have a home directory, unless a facility is set up > whereby a default home dir is set up for programs with a certain > name.
Default could also be DATAD$ or whatever. > - Via QPAC2. This would have to be changed to send the home dir > name to the thing. If it's easy enough to do no problem ;-) > - Via other file managers (which ones?). They would have to be > changed, too. CueShell, which I have acquired the sources for but didn't have a look at yet. > If there are many of them, I might envisage creating > a new trap (#3, D0 = $3F) which takes as parameter the > name of a file & excutes it (this is a facility which > I find sorely missing from the OS as such anyway). Hm, the meaning of a Trap #3 depends on a specific device you've opened, not a good choice IMO. But if you do use a #1 or #2 trap there will be no way to maintain QDOS compatibility (not that I'm particularly bothered by that, just mentioning it). > Preliminary way the Thing could handle requests > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > ->> set the home dir name > > -- get the true job ID if passed as -1 > -- try to find this job ID in my list > ----- if found, return with error > ----- else, set up string (possibly reserve more mem in chunks of 512 > bytes) As I said, I think if we/you are going ahead with this, I think it should probably be a "current directory" functionality with functions like "up one directory" and "change directory to x (absolute and relative). Or perhaps both? On other systems Applications get 2 things: a current directory and the complete name of their EXE file. > Some way must be devised to delete the filenames after a certain time. > When the job is deleted? Yes. > Should the home dir name be deleted once it has been passed back to > the job? No. > Should there be an explicit deletion? No. > Should there be a "normal" request for the home dir (doesn't delete > it) and one where deletion is automatically done after passing the > name to the job? Don't see why (and as said, a "current directory" would have to be present during the whole process anyway). We're talking about a few bytes here. Also something one should probably think about: should functions like OPEN automatically use the "current directory" if no drive name is given? Currently most commands default to DATAD$. Or, speaking completely into the blue, what about a meta device like DEV_ that uses dynamic paths instead of static ones? Something like "home_MyDataFile"? Marcel _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
