Or a completely different proposal: Lets take the standard job as the starting point. Dealing with QLiberated or Turboed jobs need some special treatment.
When a job is first started it has a code area and a data area. If there are open channels or a command line the Basic keywords EX (and family) adds the space this data requires to the dataspace and stacks that data on top of the data area. It would not be difficult to stack the home directory on top of that again thus: Home directory Command string Channel ID Channel ID .... number of channel IDs Data area At present (a6,a5) point to the top of the data area. This could now be the pointer to the directory string (alternative registers could be used instead, if better). Since the data area is private to each instance of a job, the Home Directory [HD] could easily be dynamic, ie a Current Directory [CD] instead/as well. Id propose the following format for the HD/DC area: (magic word) full file name length word directory length word string bytes bytes padding to 42 bytes bytes There would have to be some way to flag that the HD/CD was present: eg an additional magic word at the top of the structure, or some other method. For Sbasic one could simply extend the Save Name (to call it something. That is the name that is stored somewhere when you SAVE your program) system currently in place. Ie some additional keywords to read or change the Save Name string. QLib compiled programs pose a challenge as we dont have access to the compiled job's initialisation code to access that information. However, there are other, more plodding, ways to find a job's data area and locate the HD string. Thus a function such as HOMED$ or CDIR$ to read the HD string would have to work differently in compiled and interpreted mode. Thereyougo. Now shoot it down in flames! Per _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
