Inside Macintosh: Mac OS Runtime Architectures /

Chapter 3 - Programming for the CFM-Based Runtime Architecture

Multiple Fragments With the Same Name

The Code Fragment Manager associates fragments with physical entities (on disk, in memory, and so on) rather than names, even within the same closure. This referencing method means that it is possible to have the Code Fragment Manager prepare two fragments with the same name (which may or may not be identical). For example, consider Figure 3-9, which shows a hard disk that contains two separate copies of the import library mooLib.

Figure 3-9 Identical but independent fragments

When the application mooApp launches, the Code Fragment Manager determines that mooApp requires the import library mooLib and, following its search path, eventually finds a copy in the default system libraries folder (the Extensions folder, for example). This copy of mooLib is then bound to mooApp.

Later, you decide to launch the application cowApp, which also depends on the import library mooLib. However, in searching for mooLib, the Code Fragment Manager finds a copy of the library in the folder containing cowApp. Since this location takes precedence over the Extensions folder, the Code Fragment Manager binds this copy of mooLib to mooApp.

The result is that two separate copies of mooLib exist at the same time. Even though they share the same name (and may in fact be completely identical), they do not share data or code; as far as the Code Fragment Manager is concerned, they are two separate fragments. This can lead to subtle problems when the libraries have specified systemwide sharing of data. For example, even if both copies of mooLib specified systemwide data sharing, they would not share global data with each other. On the other hand, allowing multiple copies of a library to exist can be useful for test or debugging purposes. For example, cowApp could use a test copy of mooLib without disturbing the copy used by mooApp.

---

© Apple Computer, Inc.
11 MARCH 1997