Path: utzoo!attcan!uunet!decwrl!elroy.jpl.nasa.gov!usc!ucsd!pacbell.com!ames!haven!mimsy!mojo!russotto From: russotto@eng.umd.edu (Matthew T. Russotto) Newsgroups: comp.sys.mac.programmer Subject: Re: Files and Drivers Message-ID: <1990Jul26.134700.16427@eng.umd.edu> Date: 26 Jul 90 13:47:00 GMT References: <1990Jul23.201524.13849@ux1.cso.uiuc.edu> <1990Jul24.133617.8305@eng.umd.edu> Sender: news@eng.umd.edu (The News System) Distribution: comp Organization: College of Engineering, Maryversity of Uniland, College Park Lines: 30 In article urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.sys.mac.programmer, article <1990Jul24.133617.8305@eng.umd.edu>, > russotto@eng.umd.edu (Matthew T. Russotto) writes: >< In article <1990Jul23.201524.13849@ux1.cso.uiuc.edu> resnick@lees.cogsci.uiuc.edu (Pete Resnick) writes: >< > >< >1. Is this a problem as is? Will my file stay open between calls with >< >the file mark in the right place? [...] >< No problem. Files remain open unless explicitly closed. > >With one important exception: If the application which (according to >MultiFinder) opened the file quits, the file is automagically closed. >(This is only true for data forks; resource forks are assumed to get closed by >the resource manager.) >My "solution", which I use in my SingleShare server which runs in interrupt >mode and doesn't neeeed an INIT, and therefore can't get at the original trap >address (ignoring the difficulty re: data registers), is to find out where >MultiFinder remembers the appropriate values, and to poke at them immediately >after the _Open succeeds. Why not simply mess with $910? Or does MultiFinder worry about the heap and not the CurApName? Seems to me that Apple should make some way of opening the file and having it stay open-- like a constant to be added to ioPermssn, or something. Apple, are you listening? Apple? -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!