Section 2.7. The C Library

As shown in Table 21, bundles are used to implement several types of plug-ins. From a generic standpoint, a plug-in is an external piece of code that runs in a host environment. Typically the host is an application, but it can be an operating system or perhaps even another plug-in. The host must be designed to be extensible through plug-insit must export an API for the plug-in to conform to. Thus, by using the host's plug-in API, a plug-in can add functionality to the host without requiring recompilation of, or even access to, the host's source.

Note that the bundle extensions listed in Table 21 are only conventionsit is possible to have a bundle with an arbitrary extension, as long as certain requirements are satisfied or the application using the bundle knows how to handle the extension.

2.8.2. Property List Files

You will frequently come across property list ( plist ) files on Mac OS X. They are on-disk representations of organized data. When such data is in memory, it is structured using basic data types native to the Core Foundation framework.

The Core Foundation data types used in property lists are CFArray , CFBoolean , CFData , CFDate , CFDictionary , CFNumber , and CFString . An important feature of these data types is that they are readily portable across multiple Mac OS X subsystemsfor example, CF data types have analogs in the I/O Kit.

An on-disk property list is a serialized version of an in-memory property list. A plist file may store information in either binary format or human-readable XML format. ^[32] The two most common uses of plist files on Mac OS X are by bundles and by applications.

^[32] Many people opine that XML is hardly readable by humans . Although it is cumbersome for a normal person to parse, XML is decidedly more human-friendly than a "raw" binary format.

A bundle uses a special type of plist filean information property list to specify its critical attributes, which are read by other programs while handling the bundle. The default name for an information property list file is Info .plist . Consider an application bundle's Info.plist file, whose contents may include attributes such as the following:

• The document types handled by the application

• The name of the bundle's main executable file

• The name of the file containing icons for the bundle

• The application's unique identification string

• The application's version

Applications use property list files to store user preferences or other custom configuration data. For example, the Safari web browser stores a user's bookmarks in a plist file called Bookmarks.plist . Numerous configuration plist files can be found in a user's ~/Library/Preferences/ directory. Typically, applications store per-user configurations or preferences in this directory using a reverse DNS naming convention. For example, the Safari web browser's preferences are stored in com.apple.Safari.plist .

Property list files can be created and manipulated using several tools on Mac OS X. The plutil command-line program can be used to convert a plist file from one format to another. It also checks plist files for syntax errors. XML-format plist files can be edited using any text editor, although it might be more convenient (and less error-prone ) to use the Property List Editor graphical application, which is part of Apple Developer Tools. The Cocoa and Core Foundation frameworks provide APIs for programmatically accessing plist files. As alluded to earlier, several standard object types in these frameworks are stored, organized, and accessed as property lists.

2.8.3. Frameworks

In its simplest form, a Mac OS X framework is a bundle containing one or more shared libraries. Besides stand-alone shared librariessuch as the ones in /usr/lib/ Mac OS X contains a large number of frameworks. Whereas a shared library contains shared code, a framework usually contains one or more shared libraries along with other types of related resources. ^[33] From an implementation standpoint, a framework is a directory hierarchy encapsulating shared resources such as the following:

^[33] It is possible for a framework to contain no shared code but only resources.

• Dynamic shared libraries

• Headers

• Nib (NeXT Interface Builder) files

• Localized strings

• Images

• Documentation files

• Information property lists

• Sounds

A framework directory has a well-defined structure consisting of files and folders, some of which are mandatory; the others are optional. Figure 213 shows the files and folders contained in the hypothetical Foo framework.

Figure 213. Bundle structure of a Mac OS X framework

Foo.framework/

# Top-level directory

Headers -> Versions/Current/Headers

# Symbolic link

Foo -> Versions/Current/Foo

# Symbolic link

Libraries -> Versions/Current/Libraries

# Symbolic link

Resources -> Versions/Current/Resources

# Symbolic link

Versions/

# Contains framework major versions

A/

# Major version A

Foo

# Framework's main dynamic library

Headers/

# Public headers

Bar.h
        Foo.h
      Libraries/

# Secondary dynamic libraries

libfoox.dylib
        libfooy.dylib
      Resources/
        English.lproj/

# Language-specific resources

Documentation/

# API documentation

InfoPlist.strings

# Localized strings

Info.plist

# Information property list file

B/

# Major version B

Foo
      Headers/
        Bar.h
        Foo.h
      Libraries/
        libfoox.dylib
        libfooy.dylib
      Resources/
        English.lproj/
          Documentation/
          InfoPlist.strings
        Info.plist
    Current -> B

# Symbolic link to most recent version

The Info.plist file within the Resources subdirectory of a framework contains its identifying information. Frameworks support versioning: If an application depends on a particular version of a framework, either the exact version or a compatible version of that framework must exist for the application to run. Major version differences are incompatible, whereas minor version differences are compatible. A single framework bundle may contain multiple major versions. The framework shown in Figure 213 contains two versions, A and B. Moreover, all files and directories in the framework's top-level directory, except Versions , are symbolic links to entities belonging to the major version Current . Foo , the file with the same name as that of the framework directory's prefix, is the main dynamic shared library.

Figure 214 shows the standard Mac OS X frameworks categorized by the typical purposes they are used for.

An umbrella framework can contain other subframeworks and even other subumbrella frameworks. Umbrella frameworks are used to hide interdependencies between discrete system libraries by effectively presenting a metalibrary that is the union of all libraries within it. An umbrella framework's bundle structure is similar to that of a standard framework, but it also contains a subdirectory called Frameworks , which contains subframeworks. Typically, the programmer may not link directly to subframeworks. ^[34] In fact, the programmer need not know whether a framework is an umbrella framework or notlinking to an umbrella framework automatically provides access to its constituents. At runtime, if the dynamic linker comes across a symbol that has been recorded as "contained in an umbrella framework," the linker will search the umbrella framework's subframeworks, sublibraries, and subumbrellas. Similarly, an umbrella framework's header files automatically include any header files in the subframeworks. Figure 215 shows the standard umbrella frameworks on Mac OS X.

^[34] While compiling an umbrella framework, it is possible to specify through a linker option that a given client name can link to a given subframework, even though the client is externalsay, a bundle. The client name for a bundle is also set through a linker option while compiling the bundle.

Frameworks can also be private in that they are unavailable for linking by user programs. Some frameworks are private because they are embedded within other bundles such as application bundles. Mac OS X contains a number of frameworks that are private to Apple. These reside in /System/Library/PrivateFrameworks/ . Examples of private frameworks include DiskImages.framework , Install. framework , MachineSettings.framework , SoftwareUpdate.framework , and VideoConference.framework . Their privacy is manifested in the following ways from the standpoint of a third-party programmer.

• Apple does not publish the APIs of these frameworks. Even their header files are not available.

• By default, a third-party programmer cannot link with these frameworks. However, it is possible to link with a private framework by explicitly passing the full pathname of its containing directory to the linker. Doing so is unsupported by Apple.

When a dynamically linked program is compiled, the installation paths of the libraries it links with are recorded in the program. These paths are typically absolute for system frameworks that are part of Mac OS X. Some applications, particularly third-party applications, may contain their own frameworks within their application bundles. Paths to such frameworks or libraries, when recorded in an application, can be recorded relative to the application bundle.

When the dynamic link editor needs to search for frameworks, the fallback paths it uses are ~/Library/Frameworks/ , /Library/Frameworks/ , /Network/ Library/Frameworks/ , and /System/Library/Frameworks/ , in that order. Similarly, fallback paths for dynamic libraries are ~/lib/ , /usr/local/lib/ , and /usr/lib/ . Note that path searching is not performed in a user's home directory for setuid programs that are not executed by the real user.

2.8.4. Prebinding

Mac OS X uses a concept called prebinding to optimize Mach-O applications to launch faster by reducing the work of the runtime linker.

As we saw earlier, the dynamic link editor, dyld , is responsible for loading Mach-O code modules, resolving library dependencies, and preparing the code for execution. Resolving undefined symbols in executables and dynamic libraries at runtime involves mapping the dynamic code to free address ranges and computing the resultant symbol addresses. If a dynamic library is compiled with prebinding support, it can be predefined at a given preferred address range. ^[35] This way, dyld can use predefined addresses to reference symbols in such a library. For this to work, libraries cannot have overlapping preferred addresses. To support prebinding, Apple marks several address ranges as either reserved or preferred for its own software and specifies allowable ranges for use by third-party libraries.

^[35] A framework's preferred address can be specified at compile time using the seg1addr linker flag.

dyld was optimized in Mac OS X 10.3.4 such that prebinding of applications is no longer necessary. Moreover, prebinding of applications is entirely deprecated on Mac OS X 10.4.

Let us consider an examplethat of the System framework ( System.framework ). The shared library within this framework is actually a symbolic link to the libSystem dynamic library in /usr/lib/ . In other words, System.framework is a wrapper around libSystem. Let us use otool to display the load commands in libSystem to determine its preferred load address (Figure 216).

Figure 216. Listing the load commands in a Mach-O file

$

otool -l /usr/lib/libSystem.dylib

/usr/lib/libSystem.dylib:
Load command 0
      cmd LC_SEGMENT
  cmdsize 872
  segname __TEXT
   vmaddr 0x90000000
   vmsize 0x001a7000
  fileoff 0
 filesize 1732608
  maxprot 0x00000007
 initprot 0x00000005
   nsects 12
    flags 0x0
...

The vmaddr value shown in Figure 216 is the preferred load address of libSystem. We can use the C program in Figure 217 to print the names and load addresses of all Mach-O object files loaded into the program's address space and to check whether libSystem is loaded at its preferred address or not.

Figure 217. Printing libraries loaded in a program

// printlibs.c

#include <stdio.h>
#include <mach-o/dyld.h>

int
main(void)
{
    const char *s;
    uint32_t    i, image_max;

    image_max = _dyld_image_count();
    for (i = 0; i < image_max; i++)
        if ((s = _dyld_get_image_name(i)))
            printf("%10p %s\n", _dyld_get_image_header(i), s);
        else
            printf("image at index %u (no name?)\n", i);

    return 0;
}

$

gcc -Wall -o printlibs printlibs.c

$

./printlibs

0x1000 /private/tmp/./printlibs
0x91d33000 /usr/lib/libmx.A.dylib
0x90000000 /usr/lib/libSystem.B.dylib
0x901fe000 /usr/lib/system/libmathCommon.A.dylib

The update_prebinding program is run to attempt to synchronize prebinding information when new files are added to a system. This can be a time-consuming process even if you add or change only a single file. For example, all libraries and executables that might dynamically load the new file must be found. Package information is used to expedite this process. A dependency graph is also built. Eventually redo_prebinding is run to prebind files appropriately.

After a software update or installation, while the installer program displays the "Optimizing..." status message, it is running the update_prebinding and redo_prebinding (if necessary) programs.

$

otool -hv /usr/lib/libc.dylib

/usr/lib/libc.dylib:
Mach header
  magic    cputype cpusubtype filetype ncmds sizeofcmds flags
  MH_MAGIC PPC     ALL        DYLIB    10    2008       NOUNDEFS DYLDLINK
                                                        PREBOUND SPLIT_SEGS
                                                        TWOLEVEL