Volume Number: 14 (1998)
Issue Number: 9
Column Tag: Tools Of The Trade

Rez is Your Friend

by Marshall Clow
Edited by the MacTech Editorial Staff

What is Rez and why should I care?

Every Macintosh program is made up of resources. Dialogs, Alerts, String Lists, the list goes on and on. These resources have to be created by the someone, and are part of the program. Every programmer is familiar with ResEdit or Resorcerer, which let you edit resources visually. Fewer programmers know about Rez, the resource compiler.

Rez is a compiler, like a C, Pascal or C++ compiler. It takes text files (usually with the suffix '.r' ) as input, and produces a resource file as output. MPW also ships with DeRez, which takes a resource file and produces a text file that can be input back into Rez. Originally, Rez ran only under MPW, but both Symantec and Metrowerks have shipped versions of Rez as part of their integrated development environments.

In this article, I'm not going to give a tutorial on Rez. Instead, I'm going to concentrate on the reasons that you should be using Rez to manage your resources. A full manual for Rez (and DeRez) can be found in Appendix C of "Building and Managing Programs in MPW, available at ftp://ftp.apple.com/devworld/Tool_Chest/Core_Mac_OS_Tools/MPW_etc./Documentation/MPW_Reference/Bldg%26Mng_Progs_In_MPW.sit.hqx.

When first Macintosh development environments shipped (back in 1985), they included a tool called RMaker. (ResEdit didn't appear until late 1985 or early 1986) RMaker (short for Resource Maker), like Rez, was a resource compiler, translating a text file into a resource file. However, RMaker knew about only a few resource types, and was not easily extensible. So, when Apple shipped MPW 1.0 in 1986, they provided a completely new set of resource tools. Rez, DeRez, and RezDet. Joel West wrote an article for this magazine about the new tools in MPW 1.0. See www.mactech.com/articles/mactech/Vol.03/03.02/Rez-ervations/index.html for a description of those tools as they appeared in MPW 1.0.

An improved version of Rez shipped with MPW 2.0 in 1988, and Rez 3.0 included support for QuickDraw pictures.

Symantec shipped stand-alone versions of Rez and DeRez (cunningly named SA-Rez and SA-DeRez) with Think C 6, and incorporated Rez into the IDE with the THINK Project Manager 7.0 (68K) and the Symantec Project Manager (PPC).

Metrowerks incorporated Rez into their IDE starting with CodeWarrior 6.

At this point you are probably asking yourself, "Why should I care about Rez? I do all my resource editing in ResEdit/Resorcerer, why would anyone use Rez?". There are several reasons:

Comments

Since Rez source files are text files, they can contain comments about why a resource contains some information. A change history is another good thing to put here. Unless you have a great memory, you will want to put comments in your resource files so that when you look back a year (or two later), you can tell why this number in a table was changed from a 23 to a 42. Since resource files are binary data, there is no place to put comments there.

Don't underestimate the importance of comments. Would you write code without comments? They have saved me hours (or days!) of debugging on many occasions.

Macros

This is a big feature. Since Rez supports C-style macro processing, you can give symbolic names to your resource types and IDs, and use these definitions in a header file for both your resources and your C/C++ code. Whenever I see a bit of code that says something like:

   h = Get1Resource ( 'Foo!', 234 );

I cringe. I just know that somewhere down the line, someone will need to change the ID of that resource, and they may or may not find all the places that load/use that resource. I use a header file that is shared between my resource files and my source files.

// File Foo.h
#define   kNormalFooResID

// File Foo.c
   h = Get1Resource ( 'Foo!', kNormalFooResID );

// File Foo.r
resource 'Foo!' ( kNormalFooResID, purgeable ) {

If you prefer a less made-up example, here's one that uses familiar resource types:

// File Foo.h
#define   kNoAppleEventsAlert      130

// File Foo.c
   if (( Gestalt( gestaltAppleEventsAttr, &attrs )) != noErr )
      Alert ( kNoAppleEventsAlert, nil );
   else { // normal processing

// File Foo.r
resource 'ALRT' ( kNoAppleEventsAlert ) {
   { 0, 0, 200, 400 },    // bounds for the alert
   kNoAppleEventsAlert,   // the DITL associated with this alert
   {                      // Alert Stages
      OK, visible, silent,
      OK, visible, silent,
      OK, visible, silent,
      OK, visible, silent
   },
   centerMainScreen       // Where to show the alert
   };

resource 'DITL' ( kNoAppleEventsAlert ) {
// Dialog items go here
   };

To renumber the alert, all I have to do is change one line in Foo.h and rebuild. The resources will be renumbered automatically, even the reference to the DITL inside the ALRT resource.

Not convinced yet? Here's another example. Suppose that you want all the buttons in your application to have the same "look". For the sake of argument, let's say that you want them all to have the same height. Using ResEdit or Resorcerer, this is a nightmare, because you would have to go through each and every dialog and find each button, and check (and possibly change) the height of each button, to conform to your standard. Heaven help you if some UI designer or product manager decides that all the buttons need to be two pixels higher (to aid in translation to Urdu, no doubt).

Using Rez, (and a little foresight), it's a one line change!

// File Foo.h
#define   kButtonHeight      20

// File Foo.r
resource 'ALRT' ( kNoAppleEventsAlert ) {
// We've seen this before.....
   };

resource 'DITL' ( kNoAppleEventsAlert ) {{
   {260, 129, 260 + kButtonHeight, 209},
                  Button { enabled, "OK" };
   {260,  40, 260 + kButtonHeight, 120},
                  Button { enabled, "Cancel" };
   {8, 72, 23, 264},            StaticText { disabled, "Hi Mom!" };
   };
   };

When I change the kButtonHeight constant in the header file, all the buttons in the application change to match the new regime.

Of course, you can extend this for button widths, height and widths of other items.

Extensibility

Rez is extensible, i.e, you can write resource definitions for you own resource types. In fact, Rez comes with a set of header files that define the structure of all the common Mac resources types; Rez does not have any "built-in" resource types. It does have a set of built-in types that you can use as fields in your resources, such as bytes, 16 and 32 bit integers, C and Pascal-style strings, and a few others. Here's an example of a C struct definition and a corresponding Rez definition:

// In a header file
struct FooListEntry {
   short   fooIndex;
   short   fooValue;
   };

struct FooResource {
   short   fooVersion;
   short   fooMinorVersion;
   long    fooCount;
   FooListEntry   fooList [ 1 ];
//   Really a list of 'fooCount'
   };

typedef   struct FooResource FooResource, *FooResourcePtr,             **FooResourceHandle;

// --------------- Rez ---------------
type 'Foo!' {
   integer;   // fooVersion
   integer;   // minor Version
   long = $$CountOf ( fooList );   // size filled in by Rez
   array fooList {
      integer;      // index
      integer;      // value
      };
   };

// Usage
resource 'Foo!" ( kDefaultFooList ) {
   kCurrentFooVersion, kCurrentFooMinorVersion,
   {
      12, 23;      // See bug #32
      34, 45;
      45, 56;      // 54 was wrong! changed to 56 mtc 07/02/98
      123, 987;
   };
};

In a perfect world, Rez would read C/C++ structure definitions directly, and we wouldn't need to have different definitions for the same data structure. However, a Rez definition specifies exactly how to lay out the bits in the data structure, while C/C++ compilers are allowed considerable leeway in structure alignments and padding. Look at Apple's header files. All those lines that start out '#pragma options align' are there to control structure alignment so that 68K and PowerPC programs can share data structures and data files.

Source and configuration control

There are several source control systems available today. Projector, SourceSafe, SCCS, are CVS are just a few. Most of them handle binary files, but they all handle text files much better. Diffing tools are designed to work on text files. Having your resources in text files makes it much easier to track changes, additions, and deletions of resources.

Batch Processing

Since Rez files are text files, it is easy to generate them from other sources. A long time ago, I worked on a project to print to plotters. We had a database (in Hypercard!) that contained information on a variety of plotters (margins, paper sizes, commands supported, etc.). We had many people gather this information and enter it into the stack. This stack generated a ".r" file that we then compiled.

Today, a great deal of information is contained in databases. Sometimes you have to include information from a database into your application. Most databases have extensive report-writing facilities. It is usually fairly easy to make a database divulge the data that you are interested in formatted in Rez format. This also makes it easy to "refresh" the data in your application, by including up-to-date information as part of the build process. The database could hold anything, from sample data for the user to manipulate to the current structure of your web site.

Translation

One of the main reasons for the existence of resources is to decouple the user interface from the code, thereby making changes (especially translation between languages) easier. When I wrote printer drivers at HP we put all of our literal strings into a single header file, along with comments about how the string was used. When the time came for translation, we sent this single text file to the people doing the translations. They sent us back a translated file, and we built a translated driver. After that, all that was required of the translators was to adjust the layout of the dialogs, to take into account the changed sizes of some of the dialog items. Using this scheme, we were able to ship 12 different language versions of our driver software within 3 weeks of releasing our English version.

There are some resource types for which Rez is not appropriate. For example, there is no real structure for ICON (or icl8, etc.) resources. They are really just small bitmaps. So a Rez definition of a ICON resource is just a string of hex digits. Icon files are better kept as binary files, and edited with a resource editor. However, you can still have your cake and eat it too; by using Rez to assemble the final resource file. Suppose that you have an icon in a file called "Foo.rsrc", and in that file it is 'ICN#'(128). You can include it using Rez thusly:

include "Foo.rsrc" 'ICN#' ( 128 ) as 'ICN#' ( kFooIcon );

This will include the icon into your output file, while giving it the resource ID that you want (which is defined by a symbolic constant).

Keeping your resources as text files and using a resource compiler has many advantages over using a resource file editor. You can add comments to your resources, use symbolic constants, define your own resource types, and use all the tools that exist for maintaining and manipulating text files. The next time you find yourself reaching for ResEdit or Resorcerer, consider a third option. Sometimes the old tricks work best, and often Rez is the right tool.

West, Joel. "No Rez-ervations Needed!". MacTech Magazine (formerly MacTutor) 3:2 (February 1986).

Marshall Clow is a programmer. He has worked for Palomar Software, Hewlett-Packard, and Aladdin Systems. Among other things, he has written PICT Detective, Aladdin's Resource Compression Toolkit, and way too many resource processing tools. He currently works for Adobe Systems, where his title is "Bad Influence". When he's not coding, he can be found mountain biking or checking out micro breweries. He can be reached at mclow@mailhost2.csusm.edu