On 11 Jan 2005 at 10:53, John Hall wrote: (...)
> Conceptually, I'm not keen on this centralised approach - it seems > rather too Windows-like! > > Since it's an item of job-specific data, couldn't it be associated > with a job-specific data area or structure (e.g. put on the stack > prior to activation)? > > Apart from anything else, this would maintain the "self-cleaning" > property of the operating system... > True. However, how do you get at that from basic, espacially compiled basic? By the time your (new) keyword to fetch the data has been called, what is on the stack will/might have been overwritten.... The only other job-associated data structure is the job header. I am NOT willing to bet on the number of programs out there that assume that this structure is $68 bytes long... (...) > > 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). > > Trap#3 functions deal with channel IDs, not device names. Shouldn't > this be implemented as a vectored routine? Well - whatever. It mixes trap#1 (creating a job), trap#2 (opening a channel), trap#3 (getting the file into mem). However, you just made mùe think of something - it isn't possible to call the job creation trap from withing another trap, in Supervisor mode (now where have I heard that before recently?) so a vectored routine it might be. wolfgang > John > > > _______________________________________________ > QL-Users Mailing List > http://www.q-v-d.demon.co.uk/smsqe.htm > ---------------------------------------- www.scp-paulet-lenerz.com _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
