[comp.sys.mac.programmer] 10 open file limit - thanks but still puzzled

a_dent@vaxa.uwa.oz (06/14/90)

Thanks for all the advice on the 10 open file limit - all the answers seem
to point to that limit being somewhat flexible.  I don't quite understand
how this limit can be expanded dynamically (one suggestion was to write an
XCMD to do so).  Quoting page 178 of IM vol 4 "The file-control-block-buffer
is a nonrelocatable block in the system heap, the first word contains the
length of the buffer.".  I can see that something such as Suitcase, if 
named to install earlier than other INITS, might be able to stretch this
block but surely an application would stuff up other items in the system
heap, if it tried to expand the block later?

BTW, from where did you guys get your multipliers as applied to the
"number of open files" field in the boot blocks?  I checked Technotes and
IM and the couldn't spot it!

Andy Dent                     A.D. Software phone 09 249 2719
Mac & VAX programmer          94 Bermuda Dve, Ballajura
a_dent@vaxa.uwa.oz            Western Australia  6066

urlichs@smurf.sub.org (Matthias Urlichs) (06/16/90)

In comp.sys.mac.programmer, article <1990Jun15.002653.1897@vaxa.uwa.oz>,
  a_dent@vaxa.uwa.oz.au writes:
< [...]  I don't quite understand
< how this limit can be expanded dynamically (one suggestion was to write an
< XCMD to do so).  Quoting page 178 of IM vol 4 "The file-control-block-buffer
< is a nonrelocatable block in the system heap, the first word contains the
< length of the buffer.".  [...]

There's a low memory global which points to this block, and another which says
how big one FCB is. So what you do is to lock out interrupts, create a new
pointer with the appropriate new size in the System heap, copy all the stuff
over, and set the low-mem pointre to point to your block.

NB: You can't increase the size of the FCB table beyond 64k because currently,
file refnums are just offsets into that table (and they're integers).
If you increase it beyond 32k, you're bound to run into some buggy
applications which treat file refnums as signed and consider "negative"
refnums as error codes.
(I didn't test real applications for this, but I've seen sample code which
does make that assumption.)

< BTW, from where did you guys get your multipliers as applied to the
< "number of open files" field in the boot blocks?  I checked Technotes and
< IM and the couldn't spot it!
< 
It should be somewhere in the boot code, either ROM or in the System file.
You might want to compare the boot block number to the actual number of FCBs
to determine the factor -- if it's not a whole number, chances are that
someone either increased the FCB count or the number in the boot block before
you.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)