Dilwyn writes: > > I have long been wanting to have some sort of "home directory" > facility in > > Smsq, ie a way for programs to "know" which (sub)directory they were > > executed from, so that they could easily find any associated > resource files, > > eg configuration files, help files, saved settings, and the like, > without > > any further user input or configuration. > > > I totally agree - this is needed. The simplest way to apprach it would > be to change the O.S. code to execute files which then places the > execute source in a system or environment variable or perhaps in part > of the job header code, though this might make the job self-modifying. > What I;m getting at is that as the program is executed, the EXEC code > (at OS level, not BASIC of course) stores the execution drive/dir name > in somewhere where the job can access it, as it would potentially be > different for each job of course.
The current plan is to reserve additional dataspace when the job is executed and insert the home directory there, at least for normal jobs. Im hoping that this will also work for compiled jobs without any problems. For SBasics I thought of employing a similar scheme to that used by JOB_NAME to store the directory, but I havent investigated this thoroughly yet. In this case the home directory would be that of the last program file loaded, using a copy of PROGD$ as a default. As you see, it could get rather involved if I go the whole hog, and this is why it will take some time. Coming as I do from the kilobyte school of computing Im rather parsimonous regarding memory usage. Since the current plan uses up 44 bytes of overhead for each job (a two-byte marker plus device name plus the max length directory qstring) Ive been trying to figure out a way to conserve memory in cases where no home directory is wanted. One problem here is that I have no control over how compiled executables use their dataspace. Any ideas anyone? Per
