tim@hoptoad.uucp (Tim Maroney) (04/13/90)
Here's something I thought would be easy, but I can't figure it out
from disassembling the ROM.
We all know about resource file search paths, and how you can use
UseResFile to set which file is the first to be searched, so that any
files opened after the one you specify will not be searched. Fine and
dandy. But somewhere, the system must keep track of the temporarily
unused part of the search path. For one thing, it needs to get back at
the resource map when you UseResFile on the real most recently opened
file to expand the search path back to its former state. For another,
it has to be able to close all open resource files when you
ExitToShell. And so on.
So where is this information stored? It's not stored in TopMapHndl, at
least not in any obvious way. TopMapHndl is the map currently at the
start of the search path, not the file at the beginning of the total
search path. And the RM code in the ROM doesn't reference any low
memory globals other than the documented ones, which don't contain
this information.
I do realize that wherever this information is stored may change in
future system versions. I'll make a decision on whether this is any
better or worse than my current fallback solution, which involves
searching the FCB table for all open resource files. (Hint: even if
it's bad, it's probably better....)
--
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com
"Satanic is merely the name they give to the behavior of those who would
disrupt the orderly way in which men want to live."
-- Gabrielle, THE VAMPIRE LESTAT, Anne Ricearies@rhi.hi.is (Reynir Hugason) (04/15/90)
> So where is this information stored? It's not stored in TopMapHndl, at > least not in any obvious way. TopMapHndl is the map currently at the > start of the search path, not the file at the beginning of the total > search path. And the RM code in the ROM doesn't reference any low > memory globals other than the documented ones, which don't contain > this information. topMapHandle is the front most resource map of all currently open resource files in the system. UseResFile does _not_ modify this linked-list _ever_. It simply tells where it should start the search in it, you supply it with a refNum and it locates that refNum in the list and starts there, slow but neat. Consider the following diagram for a more picturesque view of UseResFile. 1. OpenResFile('R0..R3'); 2. UseResFile(R2); topMapHandle contains topMapHandle contains (..previously opened files..) (..previously opened files..) R0 R0 R1 R1 R2 R2 <- CurResFile R3 <- CurResFile R3 So as you can see it never modifies the list, and _RsrcZoneInit can simply walk the list from left to right with-out worrying about what the current search order is. Post scriptum: If you need to keep your resource files open in between application launches (e.g. some INIT doing really niffty stuff) you can do so by hiding your resource map behind the system resource map. You will have to NIL your handle fields though, but that's not too though ;-) ============================================================================== Mimir R. (aries@rhi.hi.is) | A program is like a nose. Taeknigardur, Dunhaga 5 | Sometimes it runs, sometimes it blows. IS-105, Reykjavik | ICELAND | DISCLAIMER: Who me?! ==============================================================================