mrr@mrsoft.Newport.RI.US (Mark Rinfret) (08/28/90)
A while back, I requested a reasonable approach to growing the system heap
from within an INIT. Several readers responded with references to the
'sysz' resource, which indeed does what it is supposed to.
It turns out that my problem was two-fold. I made an assumption that the
size of the system heap was the problem (it wasn't) and the little hack I
wrote to measure system heap size wasn't reporting useful info (more stuff
accumulated in the additional heap area, masking the size increase; I
didn't use a call which would have caused a compaction/purge - duh!).
It turns out that the bug was actually in the device driver which my INIT
installs. In short, it was caused by a bad pointer reference in the
CONTROL entry. Control was being called by the system because I had
needlessly set the "needGoodBye" flag in the driver resource. Multifinder
operation was masking the problem.
Thanks to all who responded.
Now, for another question...
As I mentioned, my INIT installs a new device driver (a "software" device).
This is done as follows:
- Load and detach the 'DRVR' resource
- Obtain an available driver reference number by scanning the unit table
for an empty entry. Start scanning at (-12 + 1), per an example in
Tech Note 71 (I think; the note was about scanning for device driver
names).
- Call _DrvrInstall (with the reference number)
- Get the handle to the DCE and fill in the DCE with pertinent info.
- Leave.
I don't open the driver in the INIT. The first application to call
OpenDriver with my driver's name causes dCtlStorage to be allocated. The
driver is never closed.
All of the above works very well EXCEPT when I'm running TOPS networking
software. In that case, it seems that TOPS simply clobbers my driver
installation. If I name my INIT file such that it has a leading underscore
(thus running after the TOPS init), everything works fine. Is TOPS making
assumptions or am I breaking the rules?
Mark
--
#################################################################
# Mark R. Rinfret, MRSoft Home: 401-846-7639 #
# mrr@mrsoft, galaxia!mrsoft!mrr Work: 401-849-9930 x301 #
#################################################################ts@cup.portal.com (Tim W Smith) (08/31/90)
You might want to also scan for DRVR resources in the System file that are not loaded, in order to avoid taking a unit table slot that will be needed later. Another possibility is to use an entry >= 64. These are used by the drivers for slot devices. When a slot device is opened, the slot manager scans to find an empty entry, so you don't have to worry about taking someone else's position. Tim Smith
kurash@carr.dartmouth.edu (Mark Valence) (09/05/90)
When you scan the unit table, you should start at entry #40, not #12. These lower entries are reserved by Apple, I believe. Also, you might want to check the System file for DRVRs that might use each entry, as previously suggested. Also, you probably shouldn't use Unit Table entries greater than entry #64 UNLESS you make sure that the table is that large. Some earlier Systems only allocate a table with 48 entries, and recent versions allocate a 64 entry table. Check low memory global UNtryCount (or some such name, basically, 'UnitEntryCount'), which is an integer specifying how large the unit table is. See the proper tech note to find out how to widen this table. Mark.