Editing Resource fork (section)

== Resource identifiers ==
Each resource has an [[OSType]] identifier (a four byte value), an ID (a [[signedness|signed]] 16-bit [[word (computer architecture)|word]]), and an optional name. There are standardized resource types for [[dialog box]]es (<code>DITL</code>), images (<code>[[PICT]]</code>), sounds (<!-- seems like extra space there is intentional, and preferred since padding to 4 bytes: --><code>snd </code>){{snd}} and [[executable]] binaries (<code>CODE</code>) which, until the advent of the [[PowerPC]] [[central processing unit|processor]], were without exception stored in the resource fork. Subroutines for rendering [[window (computing)|window]]s are stored in their own type of resources (<code>WDEF</code>), and subroutines for rendering menus in theirs (<code>MDEF</code>). This arrangement enabled users to easily customize not only individual applications but also the operating system itself, using tools such as [[ResEdit]] to modify the resources of an application file or any of the system files.

Within an application or other code, resources can be loaded simply using a combination of their type, ID or name, without regard to how and where they are stored in the resource fork. The client is returned a [[Reference (computer science)|handle]] to the loaded resource which can then be accessed like any other heap-based data. The OS component that facilitates this is the Resource Manager. In addition to abstracting the details of the data storage from the data, the Resource Manager also arranges sets of open resource forks into a stack, with the most recently opened file on top. When trying to load a resource, it will look in the top of the stack first, (perhaps the current document's resource fork), then the next one down (the application's resource fork), then the next one (system resource forks). This arrangement is very powerful{{snd}} it permits local resources to override more global ones lower down{{snd}} so an application can provide its own icons or fonts in place of the standard system ones, for example. It also allows an application to load resources from the system using the same API as any other resource, without regard to where or how that resource is stored{{snd}} to the application, all resources are equally available and easy to use. The system reserves resource IDs in a certain range to help avoid resource conflicts arising from this. Resource Manager APIs allow the programmer to manipulate the stack and modify the search behaviour.