HyperCard 1.x
-------------
HyperCard 1.x loaded externals with a GetNamedResource call, then tried to
make a copy of the external using NewHandle/BlockMove. If that failed, it
used DetachResource to get the external away from the Resource Manager. It
then moved the external high (MoveHHi), locked it on the heap (HLock), and
jumped to it. The reason for making a copy or using DetachResource was to
make sure the external stayed around even if the resource file it came from
got closed.
HyperCard 2.x
-------------
HyperCard 2.x uses Get1Resource to read the external from a resource file,
but it doesn't make a copy or detach the external -- it just moves it high,
locks it, and jumps into it.
This method has a potential side-effect. With HyperCard 2.x, if an external
somehow closes the resource file it came from while it is running, the
block the resource is in will be marked purgeable (by the Resource
Manager), and may be purged. Externals are usually pasted into a stack, so
if an external does something to close the stack it came from, it could end
up purging itself. An external could get purged simply by executing a
callback that caused HyperCard to go to another stack.
This article is adapted from the Claris Tech Info database.
Support Information Services