Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!snorkelwacker!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Files and Drivers
Message-ID: <q=$re2.1]1@smurf.sub.org>
Date: 25 Jul 90 20:17:41 GMT
References: <1990Jul23.201524.13849@ux1.cso.uiuc.edu> <1990Jul24.133617.8305@eng.umd.edu>
Distribution: comp
Organization: University of Karlsruhe, FRG
Lines: 40

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.)

This does matter if you open a file from a VBL task (or from a driver, or from
a desk accessory's accRun routine) and the then-running application quits.
The MacDTS-approved solution is to have an INIT which gets the trap address of
_Open, and to call that instead of the normal Open trap. (Difficulty: you have
to make sure that that Open does get called with the right trap (_Hopen,
async) which involves setting one data register, it's not documented which
one, to some magic value.)

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.
This has the major disadvantage that I'll need a new revision for each new
MultiFinder. It has the advantage that, since MultiFinder's data structures
are tagged with its signature and version number, the scheme can't break
except by realizing that the workaround isn't available.

It has also the major disadvantage that System 7.0 prohibits _Open from being
called asynchronously, which IMHO is a very bad idea.
That misfeature was introduced because the file table size is going to be
dynamic. It would be better to resize the table in the synchronous case, and
to return an error in the async case. This parallels what happens if a volume
is off-line (eg. ejected).
-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)