Rich Mellor writes:

<>
> > 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).
>
> I prefer this type of approach as it would ensure that the home directory
> (or whatever) would be removed together with the job.
>
> However, I perceive several problems with this approach:
>
> 1) Older programs which would expect (a6,a5) to point to the command
> string at the top of the data area.  If we were to adopt this scheme, then
> a lot of existing programs would immediately not be able to get at any
> parameters passed to them.  We do not have the software authors or sources
> to enable us to amend existing programs or re-write them.  I guess we
> could overcome this by amending the setup job code to have (A5,A0) (?)
> point to the location of the home directory

Not at all. Currently (a6,a5) points to the top of the data area. That
doesnt change! Only cognizant programs would attempt to peek beyond their
area into the void. There, if they were EXecuted by an equally cognizant OS,
they would find a marker that tells them that there is a HD there. If the OS
were not HD-aware the program would have to offer a warning to the user or
find some workaround. Non-HD-aware programs would not even look. Ie this
method would be wholly transparant to legacy programs.

> 2) The bigger problem and one which is harder to address...
> How do you decide what is the home directory of a file called
> win1_basic_exts_turbo_config_exe

The OS already provides that information unambiguously. In S*basic try:

    ch = FOP_IN(<path>+<name>): PRINT FNAME$(#ch): CLOSE#ch
    ch = FOP_DIR(<path>+<name>): PRINT FNAME$(#ch): CLOSE#ch
<>

Per

_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to