Mac OS X Developer Preview 2

The following came from the ADC release notes page.

Property Lists

The new function CFPropertyListCreateDeepCopy() can be used to make deep copies (mutable or immutable) of property lists.

Socket

CFSocketRef has been added to CoreFoundation. It encapsulates a native socket (of arbitrary type and protocol) so that it can read from the socket in the background and make the results available using a CFRunLoopSource. There are three ways in which this can be used: one in which the source provides the data read to the client in a CFData; one in which the source merely signals the availability of data, leaving it to the client to read it; and one in which the CFSocket accept()s new connections and the source provides them to the client. A CFSocket can also be used to write data to the socket with a timeout.

Tree

CFTreeRef has been added, primarily in support of CFXMLParser. However it can be used by itself as well.

Preferences

There is a known bug in CFPreferencesCopyApplicationList(), where the domain “any application” is reported both as “kCFPreferencesAnyApplication” (correct) and as “*” (incorrect). You can see the effects of this by executing “defaults domains” from within Terminal - the domain “*” will be listed in addition to the global domain. We ask developers to work around this by manually filtering “*” from the list of applications returned. This is fixed in DP3.

Allocator

There is now a new built-in allocator, kCFAllocatorMalloc. It uses the standard malloc() functions to do its allocations.

PlugIn

CFPlugIn now uses a more COM-like model to find and identify plug-ins. To support this functionality, a new type, CFUUIDRef, was added to CoreFoundation.

The previous mechanism (where strings were used) is still supported for binary-compatibility reasons, but recompiling will lead to warnings as the CFPlugIn functions are now declared in terms of CFUUIDRef. Please refer to the CFBundle/CFPlugIn release note for details.

CarbonLib

CFBundle, CFPlugIn, CFURL, and CFUUID are now available to Carbon applications on MacOS 9 and earlier systems where CarbonLib is shipped. Generalized XML parsing and related functionality will soon be added to this list.

Note that some CoreFoundation APIs are not planned to ever be available on CarbonLib. These include CFRunLoop, CFSocket, CFNotification.

CFM-based applications on Mac OS X also only have access to the APIs that are common subset of APIs available on both platforms. Full CoreFoundation functionality is available to Mach-O Carbon applications running on MacOS X.

URL and HFS paths

There is a known bug in CFURL’s handling of HFS paths; the HFS volume does not get properly translated to the equivalent POSIX mount point and vice versa. The effect is that URLs constructed via CFURLCreateWithFileSystemPath() with a pathStyle of kCFURLHFSPathStyle will not be properly constructed, and will not return reliable results when further CFURL function calls are made with the resulting CFURL. Likewise, CFURLGetFileSystemPath() is unreliable when passed a pathStyle of kCFURLHFSPathStyle. We ask developers to work around this by converting the HFS path to a POSIX path themselves, then creating the CFURL from the POSIX path. This is fixed in DP3.

Carbon

CoreFoundation now links against the low-level Carbon library (CarbonCore), which means that the public symbols in this library appear in the same name space as CoreFoundation. Most of the public symbols in Carbon do not use prefixes, which makes it possible for there to be symbol conflicts. The solution to this is to avoid the conflicts by renaming your symbols.