Undocumented, the resource file format? Yeah, right.
I can bring some balance to this discussion. For one, I'm actually programming on the Mac. No kidding. Using good ol' C with the Carbon API. I'm a registered (online, i.e. free) developer and I received the ADC newsletter and check the ADC website.
The resource manager is still supported in Carbon (with a few exceptions such as ROM resources, since there is no more ROM in OSX). However, it's obvious Apple is trying to get/move us (developers) away from resources.
To begin with, they are most of the time irrelevant right now. Resources are not just a storing format, but a complete virtual memory management system: the resource manager loads the resources from the drive to the memory when we ask them, then they remain on memory and we can still ask for data in them. If ever memory becomes tight, then the resource manager purges resources from memory to make room for others; if ever the program wants to access the resource that has been purged, then the resource manager (transparently) reloads the resource from the disk. This allowed to work with limited memory.
Also many managers (menu manager, for instance) were based on resources. For instance to refer to a menu, the program passed the handle of the loaded MENU resource to various functions, and could even directly modify in memory the data in the resource, which would then be used by the menu manager to draw the menu the next time the user would pick it. But now in Carbon these same managers use opaque structures to which the program does not have direct access, we have to use accesor functions, and that are not resource handles (a handle is a pointer to a pointer to the resource data, this allowed the memory manager to move this data in memory and the program still have a valid, modified pointer to it), just a pointer to the opaque structure. Menus can still be loaded from resources with the same functions, but it's just for compatibility, since in the memory they are no longer resources. We might as well load them from nibs. Which I did for my latest program.
Now, there are two separate issues. The first is the one of the resource fork. You're aware by now that it's a major pain in the ass to move in contexts (zip compression, internet transfer protocols, UNIX and Windows filesystems, etc...) that support only one fork per file. That's why resource in bundles are actually in the data fork of a file in the bundle, so that applications can be distributed more easily than non-bundle apps, that had to be compressed in .sit or encoded in .bin (even installers). Apple is tring to move away from the resource fork as fast as they can. Unfortunately, due to limitations in CarbonLib, there still needs to be resources in the resource fork of Carbon applications to make them work in OS9, so the OS9-compatible apps still have to use the resource fork.
The second issue is that of the resource format itself (in the data fork or resource fork) and the resource manager that uses them. We can still use them without problem, and since they have not been declared unsupported in Carbon, we will probably be able to use them for some time, even if the relevance of resources is no longer strong. Though for instance in Carbon nib files, some interface elements can be given a picture, that has to reside in a PICT resource in the resources of the application bundle... I'm still using one or two resources (leftover from the project template) in the application I'm working on right now; of course they are in the data fork of a xxxx.rsrc file in the bundle. Notice that I'm working with Project builder (July 2002 dev tools, that came with Jaguar), and that it cannot target OS9. Ironically, I can still use ResEdit (that isn't aware of the resoure-in-data fork scheme) for this: I just have to include the ResEdit resource file in the project instead of the main.r (a rez file that can be compiled in resources), and when building Project Builder copies the resources inside the file to the data fork or the xxxx.rsrc in the built bundle.
Apple does no longer support or updates ResEdit to try to move programmers from relying on resources, and use instead files in the bundles (such as images), xml stuff for settings and preferences, and nibs for UI elements (menus, windows, dialogs, controls). But resources will continue to be used, though it makes the work of people who work on "resources" (in the general sense, that is stuff in the bundle that's not the executable), such as localisers, harder since they have to use ResEdit on Classic mode or expensive or limited resource editors, instead of interface builder, an xml editor, and the actual editors for the files (for intance images).
