Wolfgang Lenerz writes:
> > > It will be set up as a "thing" (since I don't think we have found any
> > > other satisfactory solution for compiled Basic).
> >
> > "We" havent really tried, but ok
>
> Go ahead!!!!!!!
But why? Its enough to know it can be done without knowing how ;)
Actually I can think of one sure method to find a Home Directory [HD]
string. Taking the structure to look like this:
stack (a7)
channel count
channels
command string
magic (.w) <- (a6,a5) (as at present)
program's name length (.w)
HD's length (.w)
program's name bytes
padding of above to 42 bytes
Algorithm:
get job info
find start of allocated memory list
scan through list:
if memory ID <> my ID: next
if length of block < 52 bytes: next
if the word at block_length - 48 <> magic: next
HD found: exit scan
end scan
Another way would be to analyse QLib_rext or trace a running program to
determin whether QLib retains any memory of its original data area. If it
does, say in a6, then all that is needed to find the HD string is the
correct offset. If it doesnt, eg it releases this memory again, this method
wont work.
A third way would involve a hybrid between the Thing and the Stack schemes:
Let the EX code link the dataspaces of all jobs under its auspices using
part of the area to store its information. No need to reserve an additional
memory area whenever a job is started. Thus a different structure could be
used:
stack (a7)
channel count
channels
command string
Link to next dataspace (.l) <- (a6,a5) (as at present)
Any other household info the Thing needs
program's name length (.w)
HD's length (.w)
program's name bytes
padding of above to max bytes
Any Other Business
Remember, all this dataspace is invisible to legacy programs. The memory is
perfectly legally there, but the legacy program wouldnt know anything about
it. No marker is needed because all data is at known offsets.
The mechanism would be the same as I understand you were thinking; that when
a job is removed, the Thing is freed. The Free rutine unlinks the dataspace
and the kill job function (sms.frjb) releases the memory. So its clean,
lean, less messy than having a different memory area to store the details,
compatible with legacy software, and cognizant programs running on a legacy
OS will be warned unless the Thing is there.
> (...)
>
> > Both. By why not re-use the DUP & DDOWN code as a general utility to
> > work on any filename string, given the string's location? Suggest the
new
> > Sbasic keywords be called UD, DD and CD (CD -> Change dir, ie set a
> > new start string) ie, something quick and simple (though admittedly a
> > two char name is potentially dangerous)
>
> NOT trivial.
What is not trivial? The implementation? or reusing DUP/DDOWN? As for the
principle, I believe that is what Marcel is proposing with his Current
Directory.
> > [Note: Since we're still in "brainstorming mode" I reserve the right to
> > make /outrageous/ and even downright /stupid/ suggestions without being
> > smirked at at future QL shows, ok? ;o]
>
> Ok, we'll just smirk here, then...
That was a very discreet one ;)
<>
Per
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
