Mac OS X Developer Preview 4#

The following came from the ADC release notes page.

CFBundle#

The following CFBundle APIs are new:

CFTypeRef CFBundleGetValueForInfoDictionaryKey(CFBundleRef bundle, CFStringRef key);

This returns a localized value for an info dictionary key from InfoPlist.strings if one is available, and the non-localized value from the Info.plist otherwise.

CFURLRef CFBundleCopyPrivateFrameworksURL(CFBundleRef bundle);

CFURLRef CFBundleCopySharedFrameworksURL(CFBundleRef bundle);

CFURLRef CFBundleCopySharedSupportURL(CFBundleRef bundle);

CFURLRef CFBundleCopyBuiltInPlugInsURL(CFBundleRef bundle);

These functions return URLs for various locations within the bundle.

Boolean CFBundleGetPackageInfoInDirectory(CFURLRef url, UInt32 *packageType, UInt32 *packageCreator);

This returns TRUE and returns by reference the type and creator from the PkgInfo file, if they are available; otherwise it returns FALSE.

SInt32 CFBundleOpenBundleResourceFiles(CFBundleRef bundle, short *refNum, short *localizedRefNum);

This function opens (read-only) and makes current the non-localized and then the localized Resource Manager-style resource files (if available) for the bundle, and returns reference numbers for them. If it is called multiple times, it opens the files multiple times, and returns distinct reference numbers. Note that when an application is launched, this is done automatically so that the application’s resources will always be available. For bundles other than the main bundle, this function would have to be called explicitly.

This function looks for the bundle’s localized Resource Manager-style resources in the data fork of a file called Localized.rsrc in the appropriate .lproj directory. It looks for the bundle’s non-localized Resource Manager-style resources in the data fork of a file called .rsrc, stored with other non-localized resources, where is the name of the bundle’s main executable. For backward compatibility, if this file does not exist, it will also look in the resource fork of the bundle’s main executable.

A bundle can always contain other Resource Manager-style resource files, which could be located using (for example) CFBundleCopyResourceURL, and then opened using Resource Manager calls. The CFBundleOpenBundleResourceFiles function will simply do all of this conveniently for you for one specific set of files.

Using the Debug Version of CoreFoundation#

The standard version of CoreFoundation in general does not check for programming errors such as bad parameters, out of bounds indexing, invalid mutations, etc. The debug version, on the other hand, does, and it’s a good idea to run against the debug version of CF whenever you suspect a CF or CF usage problem.

Rather than moving binaries around or rebuilding a “debug” version of your app, you can now do this easily from the command line by setting the environment variable DYLD_IMAGE_SUFFIX to the string “_debug” (without the quotes) in your shell, then running the program from that shell.

This instructs the dynamic loader (dyld) to load _debug versions of libraries whenever it finds them, instead of the standard versions. Basically what happens is the specified string is appended to library names as an optional suffix.

Changes to CFXMLParser#

CFXMLParser’s API has changed extensively since DP3. The CFXMLDataTypeDescription structure has been replaced by a new CFType, CFXMLNode. All the callbacks and functions which used to pass CFXMLDataTypeDescriptions have been changed accordingly. To reflect this change, the parser’s version has been increased to 1; passing a version of 0 will now cause parser creation to fail. Please see the headers CFXMLParser.h and CFXMLNode.h for details.

CFPreferences#

CFPreferences now stores application preferences under the application’s bundle identifier, instead of the application’s name. This is to prevent conflicts between different applications with the same name; if the bundle identifier has not been set, preferences will be stored under the application’s name as before. For more on the bundle identifier, see /System/Documentation/Developer/ReleaseNotes/InfoPlist.html.

Run Loop API Changes#

There have been several changes to the API in CFRunLoop.h. The DP3 CoreFoundation release notes warned of these changes. Obsolete functions will be removed after DP4. Programs which use these functions, or their new equivalents, will NOT be binary compatible with the next release of Mac OS X. Normally, Carbon programs should be using the Carbon event APIs, and Cocoa programs the Cocoa event APIs, instead of using CFRunLoop directly.

To convert to the new CFRunLoop APIs, you must #define CFRUNLOOP_NEW_API before the header #include directives in each source file in which the old APIs were used.

  • The constant kCFDefaultRunLoopMode is obsolete; use kCFRunLoopDefaultMode

  • The function CFRunLoopAbort() is obsolete; use CFRunLoopStop()

  • The function CFRunLoopCopyNextTimerFireDate() is obsolete; use CFRunLoopGetNextTimerFireDate()

  • The function CFRunLoopTimerCopyNextFireDate() is obsolete; use CFRunLoopTimerGetNextFireDate()

  • The functions CFRunLoopGetNextTimerFireDate() and CFRunLoopCopyNextTimerFireDate() are not implemented, and return 0.0 and NULL respectively

  • The function CFRunLoopTimerCreate() has changed arguments, and has an additional flags argument; for the flags argument, 0 should be used, as there are no flags defined currently

  • The function CFRunLoopRunInMode() now returns a enumeration value and takes an additional boolean, which determines whether or not the function returns after a source has been handled

  • The function CFRunLoopTimerSetNextFireDate() has changed argument types

  • The new well-defined mode kCFRunLoopAnyMode is not yet implemented

  • The perform() callback in the CFRunLoopSourceContext1 structure, for version 1 type sources, has a new argument, the length in bytes of the first argument