Why does SuperCard store resources in both the data and resource forks?

The Macintosh Resource Manager is a very generalized system, and is therefore not optimized for any particular task and carries with it some limitations. Among these limitations is the number of resource fork which may be open at any time. When Supercard was fist created, the number of open resource forks possible was, if memory serves, around 14, and this may not be significantly different from the current System 7.5 implementation. So think about it: SuperCard, the SharedFile, the Runtime Editor, your application, a couple of its documents, a few projects from the Utility Palette folder - boom! you're already at the limit. Also, the Resource Manager has a lookup hierarchy based on which resource fork was most recently opened, and not necessarily related to the topmost window. It would therefore be possible for an icon in another project to be mistakenly displayed in your project if that other project was opened later. HyperCard gets around this by opening and closing resource forks on the fly on "suspendStack" and "resumeStack", but this could eat a lot of time in SuperCard's world, where multiple projects can be used truly simultaneously, with "setWindow" and other commands related to multiple project management. So by having the most commonly-used resources in its own private "resource" storage area in the data fork with the rest of the project data, SuperCard is able to deliver a system significantly more optimized for its needs. One of the additional bonuses of SuperCard's scheme is the speed with which it can locate and load XCMDs and XFCNs, which is usually about 2-5 times faster than in HyperCard. For frequently-called externals, this can make a significant difference in throughput.