Legacy Document

Inside Macintosh: Mac OS Runtime Architectures /

Chapter 1 - CFM-Based Runtime Architecture / The Structure of Fragments

Fragment Storage

The physical storage unit for a fragment is called its container. A container can be any logically contiguous piece of storage, such as the data fork of a file (or some portion thereof), the Macintosh ROM, or a resource. The System 7 version of the Code Fragment Manager recognizes two container formats, the Preferred Executable Format (PEF) and the Extended Common Object File Format (XCOFF). Note that compatibility with these formats is not a requirement of the CFM-based architecture, and it may change in the future.

• The Preferred Executable Format (PEF), as defined by Apple Computer, is the current standard executable file format for CFM-based architectures. PEF provides full support of a fragment's attributes. See Chapter 8, "PEF Structure," for more details of this format.
• The Extended Common Object File Format (XCOFF) is a refinement of the Common Object File Format (COFF), the standard executable file format on many UNIX®-based computers. XCOFF containers tend to be larger than their PEF counterparts and often take longer to load into memory. XCOFF containers do not support initialization or termination routines, and they do not store version information for import library compatibility checks. XCOFF is supported on Mac OS-based computers primarily because early development tools produced executable code in the XCOFF format.

Note

Not all object code in the XCOFF format can execute on Mac OS-based computers. Any XCOFF code that uses UNIX-style memory services or that otherwise depends on UNIX features does not execute correctly on Mac OS-based computers. XCOFF output from a compiler also does not execute.