Mac OS X Public Beta “Kodiak”

The following came from the ADC release notes page.

CFBundle changes

Prior to Public Beta, CFBundleCopyResourceURL() and related functions (including related NSBundle methods) may under some circumstances have accepted a resourceName argument that contained path separators (‘/’ on Mac OS X). On some file systems, they may also have allowed case-insensitive matches for the resourceName. In Public Beta, this is no longer the case; a resourceName containing path separators will not match any file, and matches are always case-sensitive.

In Public Beta, the localized and non-localized resource manager resource files for a bundled application will be merged into a single resource map when they are loaded. Previously, they had appeared as two separate resource maps. For bundles other than applications, the existing functions CFBundleOpenBundleResourceMap() and CFBundleOpenBundleResourceFiles() are now distinguished by the fact that the former performs this merging while the latter does not. In all cases, repeated calls to these functions will create new read-only resource maps. Maps created by either function can be closed using CloseResFile(); in the case of CFBundleOpenBundleResourceFiles(), it is necessary to close each returned map individually, while in the case of CFBundleOpenBundleResourceMap(), only the single returned map need be closed. CFBundleCloseResourceMap() is also available, but in its current state it does no more than CloseResFile().

New APIs have been added to CFBundle that allow access to resources on a per-localization basis, and finer-grained access to the details of CFBundle’s localization algorithms.

CFArrayRef CFBundleCopyBundleLocalizations(CFBundleRef bundle);
/* Lists the localizations that a bundle contains. */

CFArrayRef CFBundleCopyPreferredLocalizationsFromArray(CFArrayRef array);
/* Given an array of possible localizations, returns the one or more */
/* that CFBundle would use in the current context. To find out which */
/* localizations are in use for a particular bundle, apply this to */
/* the result of CFBundleCopyBundleLocalizations. */

CFURLRef CFBundleCopyResourceURLForLocalization(CFBundleRef bundle, CFStringRef resourceName, CFStringRef resourceType, CFStringRef subDirName, CFStringRef localizationName);

CFArrayRef CFBundleCopyResourceURLsOfTypeForLocalization( CFBundleRef bundle, CFStringRef resourceType, CFStringRef subDirName, CFStringRef localizationName);

CFUserNotification changes

A new function has been added to CFUserNotification that provides for the creation of a runloop source.

CFRunLoopSourceRef CFUserNotificationCreateRunLoopSource( CFAllocatorRef allocator, CFUserNotificationRef userNotification, CFUserNotificationCallBack callout, CFIndex order);

where

typedef void (*CFUserNotificationCallBack)(CFUserNotificationRef userNotification, CFOptionFlags responseFlags);

This is an asynchronous alternative to the existing synchronous CFUserNotificationReceiveResponse().

CFXMLNode API

The constant kCFXMLNodeMacOSXVersion has been removed. Use kCFXMLNodeCurrentVersion instead.

CFStringGetSystemEncoding

The system encoding value returned by CFStringGetSystemEncoding() function is now configurable and can be changed per-user basis.

Run Loop API Changes

The CFRunLoop changes described in the release notes for DP4 below have been made permanent and the old APIs are now gone.

New run loop-related APIs

Two types of run loop sources, CFMachPort (CFMachPort.h) and CFMessagePort (CFMessagePort.h) have been added to the public CoreFoundation API. CFMachPort is a wrapper type for Mach ports, which allows Mach ports to be added to the CFRunLoop as sources. CFMessagePort provides a message-based communication channel between client/server processes on the same machine. CFMessagePort takes a client/server-defined message identifier value (a positive integer) which is normally used by a server to decide which operation should be performed, and arbitrary CFData, which ordinarily would contain the arguments to the server operation. The meanings of message IDs and the format of the data blob are agreed upon by the server and clients; CFMessagePort does not provide any structure or policy for those items. CFMessagePort messages can be one way, or round-trip and include a return data from the server.