No Rez-ervations Needed!

By Joel West, Western Software Technology, MacTutor Contributing Editor

Facing the Future

Since the last installment of Resource Roundup, there have been some major changes Mac-wise around here.

As the tag line suggests, I have a new venue, in this case working full-time on the Macintosh in a company headed by yours truly. My Mac Plus showed up and the 512K is gone (sold, not stolen like the 128 ). Now if only I had Alan Kay’s Dynabook-style Mac, rumored due late in ’88: in writing this at 41,000 feet, my Mac is useless in the overhead compartment.

However, it isn’t the prospect of swapping floppies 40 hours a week that prompted me to buy a hard disk. True, with the Ram Cache set at 384k, my Mac Plus with a Peak Systems hard disk seems at least 3x as fast as those 400k floppies. (The Peak Plus-30 was the cheapest 30mb I could find). However, I hate to agree with Steve Jobs -- whose closed-architecture Mac design was admitted a failure by John Sculley -- but the Plus30’s fan is driving me bonkers.

No, the reason W.S.T. emptied its bank account could be found on the 13 MPW floppies that had been lying around unused for a few weeks. I cheefully installed these floppies on the Peak Plus-30, tying up about 4 mb in the process. Which brings me to the subject of this month’s Resource Roundup:

MPW!

Macintosh Programmer’s Workshop is a complete development environment, and Apple’s long awaited “official” Macintosh-based development tool. Since the Lisa’s are no longer made and, after the long-rumored slotted Mac is introduced next month, no one would want one anyway, Apple is nearing completion of a two-year project to make Macintosh-based development available, both in-house and for outside developers.

At this writing, Macintosh Programmer’s Workshop is in release 1.0B2, meaning the second “beta” test release. It is rumored the complete MPW system will be in final release after the January Mac Expo, which should mean "by the time you read this!" Check with APDA on it's final status.

MPW includes a shell, editor, various utilities, 68000/68010/68020 assembler, C, Pascal and the MacApp extensible application. Encouragingly, the MPW object code format is straightforward, and the documentation describes it in enough detail for use by third-party compilers. (I’ve written and maintained compilers with more cryptic documentation than that.)

But of course, the focus here is on resources, and MPW has plenty to talk about. MPW comes with three new resource tools: Rez is a resource compiler; DeRez is a resource decompiler; and RezDet performs rigorous consistency checks on resource forks.

All three are implemented as MPW tools, which means these are invoked from within the MPW programming environment with a UNIX-like line-oriented command. If you grok UNIX, Rez reads from standard input and writes to a resource fork. DeRez and RezDet read from a resource fork and write to standard output. Of course, the standard input and output of MPW apply to the data fork of any file they access, ignoring the resource fork, if any. Normally, standard output is the screen, and standard input is redirected from a file using the UNIX-like “<” notation.

The Pascal compiler also includes the source to ResEqual (It seems misspelled to me ) as a sample MPW tool for those who want to write their own. The tool compares the resources in two files, and reports the differences (if any) by resource type and number. As a tool, it has limited utility, but it illustrates how to use Resource Manager calls to read unknown resources, such as those added in a user-configurable application.

MPW also includes ResEdit, the same one that has been pre-released in the various software supplements. MPW 1.0B2 comes with 1.0A1 version of ResEdit (A for “Alpha”, or first-level field test); however, this is labeled 1.0D11 (D for “Development”, or internal testing), certainly not the latest version available at the release date, but perhaps the most stable. ResEdit is, as before, a stand-alone window-oriented application, rather than a line-oriented MPW tool. As with other conventional Mac applications, it can be called from within the MPW shell, although not as flexibly as an MPW tool.

How to Get MPW

MPW can be purchased by anyone from the Apple Programmer’s and Developer’s Association (APDA, 206-251-6548). If you haven’t heard about APDA yet, you obviously haven’t been reading the ads in MacTutor! APDA is Apple’s latest attempt to provide a mechanism for supplying technical information and software to the thousands of Mac owners out there who want it (though it also applies to the Apple II). I can only hope it turns into a reliable and timely conduit for such information.

If you’re an APDA member ($20), you can order the base MPW configuration for $100; this includes the shell, utilities, assembler, linkers and, of course, the resource tools. The C and Pascal compilers are $75 extra; MacApp is $50, but it requires the Pascal compiler.

However, the fine print in the APDA catalog says:

This is a beta version of a product that will eventually be sold through 
Apple retail outlets.  Purchasing this version does not entitle you to 
a discount or free upgrade on the final product.

This is, of course, the most anti-user upgrade policy possible. On the other hand, this will probably have its desired effect, which is to discourage all but the most eager MPW-lover from buying it prior to its commercial release (The APDA/Dealer official status should be determined by Expo time, so check for an updatted status. It may be distributed to Apple dealers by this time.)

Even if you decide not to get MPW, let’s hope that third party companies license a version of the MPW resource tools, as the improvements over earlier tools are as dramatic as night and day. However, these improvements come at a price

La Plus Ça Change

Perhaps the one thing I retained from a semester of college French was the saying

«La plus ça change, la plus la même chose.»

which is a fancy way of saying, “The more things change, the more they stay the same.”

The resource tools of the Macintosh Programmer’s Workshop are nothing like those of earlier development systems. They are radically different, definitely better, but are also completely incompatible. Macintosh developers have been suffering through a series of incompatibilities (when did YOU finally get an HFS-compatible update on your development system?), and this is the latest from Apple. (There is a clean migration path, as we’ll see later.)

On the other hand, I’d like to hand it to Apple for not being hide-bound to tradition and stifling innovation for the name of compatability. The new resource formats are also more clearly thought out, extensible, coherent and without the ad hoc flavor of their predecessors. (Besides, it gives writers like me a way to make money!)

The MPW shell provides a demonstrable improvement in convenience and speed over most other development systems, which tend to use “Transfer” menus or their own mini-finder. The Think Technologies (Lightspeed C and Pascal) programming environment is the only one I’ve seen of comparable power. Ironically, it is more Mac-like than Apple’s MPW environment, which resembles a line-oriented operating system (e.g., UNIX) grafted onto a windowing computer (e.g., a Sun). The two approaches each have advantages, but I’d say the choice is more a matter of personal preference.

However, there’s no denying that when it comes to resources, MPW extends the standard for development systems. The two (and a half) new tools provide needed functionality, but more importantly, the MPW resource tools are far more flexible than their predecessors.

The MDS Era

By now, you’re probably familiar with the Lisa resource compiler input format. It was the one used in the looseleaf Inside Macintosh and most of the early writing about Macintosh development. (Although I’d say there was disappointingly little written about resources, which is one reason I volunteered to write Resource Roundup.)

If you’ve ever used REdit to disassemble a resource, what you got was Lisa format. The Dialog Creator is another tool that uses this format. This is a nicely done and useful tool, but it would be a lot more useful if only it could read a resource fork of an application under development!

So if you check your bookshelf, you’ve probably got all this documentation that uses the Lisa resource compiler. But if you’re like me, a small-sized developer (or serious hobbyist), you never could afford two machines, or at least justify the Lisa to the family finance committee. So instead, you purchased one of the many third party Mac-based development systems.

Most of these systems borrowed some or all of their utilities from MDS, Apple’s Macintosh 68000 Development System. So far, I’ve owned Microsoft Basic, UCSD Pascal (MacAdvantage), Megamax C, Rascal, TML Pascal, MacMETH Modula-2 and Lightspeed C. MS-Basic, MacMETH and Rascal don’t include resource tools. All the others came with RMaker, the MDS resource compiler.

RMaker and the Lisa resource compiler of course run on different machines. But from a documentation standpoint, the main difference is the input syntax. Dave Wilson published a list of the syntax of these two resource formats in a previous issue of MacTutor (Volume 2 No. 6 June '86).

Table 1 shows the list of resource types supported by the two resource compilers. RMaker is more or less a subset of its Lisa counterpart. Those resources not supported by RMaker (or either one) must be input as GNRL resources. A the format of a GNRL-defined resource is not known by the resource compiler; instead, it is input with each instance of the resource. (This is an important difference from MPW, as we’ll see later.)

Supported by MDS and Lisa

ALRT Alerts

BNDL Application bundle

CNTL Control

DITL Dialog/alert item list

DLOG Dialog box

FREF File references

GNRL General type

MENU Menu

STR String

STR# List of strings

WIND Window

Supported by Lisa only

ANYB Arbitrary bytes from a file

CDEF* Control definition procedure

CURS 16-by-16 cursor

DRVR* Driver/DA

FONT Text font

FKEY* Function key

FWID Font width table

HEXA Hexadecimal literal

ICON 32-by-32 icon

ICN# List of icons (usually for Finder)

MDEF* Menu definition procedure

PACK* Package

PAT 8-by-8 pattern

PAT# Pattern palette

PICT QuickDraw picture

WDEF* Window definition procedure

*Implemented using PROC resources with MDS

Table 1: Resource types for Lisa and MDS resource compilers

The definition of a GNRL resource begins with the target resource type, followed by a series of data fields. Each field is preceeded by .P, .I, .L, or .H, which allow specifying Pascal strings, integers, long intergers, or hex data by respectively. (Two other forms, .S and .R, are documented but rarely used.) Example 1 shows how the GNRL format is used to input a missing resource type under MDS.

In the case of DLOG and BNDL resources, the formats are actually incompatible. Example 2 shows the MDS and Lisa equivalents of these resource types.

TYPE ICON = GNRL
  ,128
.H
0001 0000 0002 8000 0004 4000 0008 2000
0010 1000 0022 0800 0044 8400 0089 0200
0100 4100 0224 9080 0448 2040 0802 4020
1124 8010 2249 0008 4480 3F04 8124 4082
4248 8041 2091 3022 1121 C814 084E 7F8F
0412 3007 0221 0007 0100 8007 0080 6007
0040 1FE7 0020 021F 0010 0407 0008 0800
0040 1000 0002 2000 0001 4000 0000 8000

Example 1: Creating resources using GNRL

MDS format

Type DLOG
 , 305 (32)
60 90 190 422
Visible GoAway   ;; status
305;; corresponding DITL
1;; shape procedure
0  ;; reference value
Align   ;; name

Type BNDL
   ,128
MACA 0  ;; owner type and ID
ICN#    ;; desktop icons
0 128 1 129 2 130;; appl., 2 docs
FREF    ;; file types
0 128 1 129 2 130;; (same as ICN#)

Lisa format

Type DLOG
 , 305 (32)
60 90 190 422    ;; boundary RECT
Visible 1 GoAway 0 ;; procID and ref con
305     ;; corresponding DITL
Align

Type BNDL
   ,128
MACA 0  ;; owner type and ID
2;; number of types
ICN#    ;; desktop icons
0 128 1 129 2 130;; appl., 2 docs
FREF    ;; file types
0 128 1 129 2 130;; (same as ICN#)

Example 2: Different resource formats for MDS and Lisa resource compilers

What’s New, Pussycat?

The format of input to MPW’s Rez is completely different. Unlike previous schemes, the syntax is consistent and not context-sensitive.

For example, do you know what the remark delimiter is in the MDS/Lisa RMaker? If you answered “*”, you’re half right. If you answered “;;”, you also get partial credit, since both are used in RMaker, depending on the position within the line. RMaker also may or may not ignore leading spaces, blank lines, and continuation characters, depending on the context. Get the idea?

Under Rez and MPW, the remark syntax is the same no matter where it is used. As with a programming language, blanks and line breaks are ignored, except when part of an explicitly-delimited literal string.

Glance at Example 3, which shows some sample Rez input data. The shock should be far less if you are an experienced C programmer: the format is similar to the constant initializers for a C struct. The use of delimiters for the structure, strings and event comments are the same as C. Each of the fields of a resource (struct) are separated by commas.

This is a logical development, since resources were always designed as a structured file format analogous to database records. The choice of C was a natural one, since C is (notoriously) terse, and also since Apple itself is discovering the value of C for systems programming.

Overall, Rez input is easier to read, mostly because of an increased availability of symbolic names. For example, is

Cancel, visible, silent,
Cancel, visible, silent,
OK, visible, 2,
OK, invisible, 1

or

CC61

an easier way to read an ALRT stages word? On the other hand, it may be harder to write at first -- more like a programming language, in fact -- since there are balanced delimiters and misspelled keywords to worry about.

Through the use of quotation marks to delimit strings, the new syntax eliminates the problems with spurious leading and trailing spaces in strings. Also, it’s easy to continue long strings across record boundaries, because two successive strings (without a comma between them) are treated as one string. As with the earlier resource formats, Rez uses a C-style escape convention for special characters within literal strings. For example, the notation "\0x0D", "\r" and "\015" can be used for a Return character.

Rez is run from within the MPW shell using a line-oriented command (no double-clicking here!), as in:

Rez -o MyApp Types.r MyApp.r

which takes a source text file called MyApp.r and writes the equivalent resource fork to MyApp, presumably your application. (Types.r will be explained in a minute.) If no output file is specified using -o, the output ends up in Rez.out, which isn’t inspired, but reflects a consistent convention used by MPW tools.

Rez (at least in 1.0b2) will clobber anything currently in the output file (including CODE resources). Fortunately, the MPW linker won’t clobber anything other than CODE resources, so as long as you Link more often than Rez, and always Link after Rez, you’re in good shape.

This is pretty easy to do, since MPW offers a UNIX-like Make facility, which attempts to guess at the minimum set of commands necessary for rebuilding. (MPW’s Make, like the UNIX version, will err on the conservative side -- extra compiles -- unless you override it.) Since the MPW shell includes a command programming language, you can also make a “brute force” command procedure to rebuild everything.

But wait, there’s more

resource 'DLOG' (305, purgeable) {
 {60, 90, 190, 422}, /* boundary */
 dBoxProc,/* procID */
 Visible, /* visibility */
 GoAway,
 0,/* refCon */
 305, 
 "Align"};/* Title */

resource 'BNDL' (128) {
 'MACA',
 0,
 { 'ICN#',/* desktop icons */
 { 0, 128;/* application */
 1, 129;/* document #1 */
 2, 130 /* document #2 */
 };
 'FREF',/* file types */
 { 0, 128;/* application */
 1, 129;/* document #1 */
 2, 130 /* document #2 */
 }
 }
};

resource 'ALRT' (128) {
 {40, 40, 180, 240},
 128,
 OK, visible, silent,/* Stage #4 */
 OK, visible, silent,   /* Stage #3 */
 OK, visible, silent,   /* Stage #2 */
 OK, visible, silent /* Stage #1 */
};

resource 'DITL' (128) {
 {/* Item #1 */
 {104, 75, 124, 135},
 Button {
 enabled,
 "OK"
 };
 /* Item #2 */
 {12, 19, 93, 184},
 StaticText {
 disabled,
 "^0"
 }
 }
};

Example 3: Sample Rez input

type 'WIND'
{rect;  /* bounds */
 integer documentProc,dBoxProc,
 plainDBox,altDBoxProc,
 noGrowDocProc,rDocProc=16;
 byte invisible,visible;
 fill byte; /* unused */
 byte noClose,hasClose;
 fill byte; /* unused */
 longint; /* refcon */
 pstring; /* title */
};

Example 4: Variant records in Rez definition

How Do They Do It?

The Rez resource compiler is completely extensible to cover any resource. The entire vocabulary is defined through a definition file, which you can change if you don’t like the spellings or defaults. (A future installment of Resource Roundup will describe how to extend ResEdit.)

This file, normally called Types.r, is a line-oriented text file with a syntax that (suprise!) resembles C. Rez is mostly just a program that understands how to read this file, and write resource data and maps. (The names of the resource attributes -- such as sysheap, purgeable, locked -- are hard-coded, but this is a minor inflexibility.)

The definition syntax differs from C in that the names of the variables (fields) are missing, so the declaration consists only of the type of the variable,

type 'ALRT'
{
rect; /* bounds */
integer;/* DITL id */
integer;/* stages (cheating) */
};

so if you want the variable name, you have to include it as a comment. 
 (The syntax provides a half-hearted support for arrays of variables 
and struct’s, and these do have a name.)

Rez uses a slightly bastardized scheme of implementing enumerated variables. The enumerated names are listed right after the field name, without the braces used in C. As in C and Pascal, the enumerators are assigned to cardinal numbers, beginning with 0. Like C, the enumeration can be skipped to an arbitrary value by specifying it as a constant. Example 4 shows how this is used in declaring different window (defprocs) in a WIND resource.

Unlike C, a variant record is implemented using a quasi-executable syntax (the C switch), rather than as a union. The data value used to select the variant is a constant of arbitrary size and location within the variant record.

If you’re a Pascal, Modula-2 or Ada programmer, C’s struct is similar to a Pascal record, but there are some other syntactic adaptations necessary:

Description C Pascal

Block {} BEGIN END

Remarks /* */ {} or (* *)

Hex constant 0xAB $AB

Alternate choice switch(e) CASE e OF

Quotation marks (“double quotes”) are used consistently for strings throughout.

Example 5 shows the syntax of the input format for the most common resources.

resource 'ALRT' (129) {
 {50, 50, 250, 250},
 129,   /* corresponding DITL */
 OK, visible, 3,
 Cancel, visible, 3,
 Cancel, visible, 3,
 Cancel, visible, 3
};

resource 'BNDL' (128) {
 'MPNT', 0,
  {'ICN#', { 0, 128; 1, 129};
 'FREF', { 0, 128; 1, 129}
 }
};

resource 'CNTL' (128) {
 {63, 141, 186, 172},
 0,/* initial value */
 invisible,
 1,0, /* minimum, maximum value */
 pushButProc,  /* type of control */
 0,/* reference constant */
 "Stop" /* title */
};

resource 'DITL' (128) {
  {{112, 112, 132, 192}, /* Item #1 */
 Button {
 enabled, "OK"
 };
 {16, 64, 36, 235}, /* Item #2 */
 StaticText {
 disabled, "Please enter your name:"
 };
 {48, 8, 64, 56},  /* Item #3 */
 RadioButton { 
 enabled, "Mr."
 };
 {64, 8, 80, 56},  /* Item #4 */
 RadioButton {
 enabled, "Ms."
 };
 {80, 8, 96, 56},  /* Item #5 */
 CheckBox {
 enabled, "Dr."
 };
 {56, 72, 76, 250}, /* Item #6 */
 EditText {
 enabled, "***Your name here***"
 }
 }
};

resource 'DLOG' (128) {
 {100, 100, 254, 380},
 documentProc, /* window shape */
 visible,
 noGoAway,
 0,/* refCon */
 128,   /* corresponding DITL */
 "Dialog box"  /* Title */
};

resource 'FREF' (128) {
 'APPL',  /* file type */
 0,/* corresponding ICN# */
 ""/* name (not used) */
};

resource 'ICN#' (128, preload) {
  {
 /* Data */
 $"0001 0000 0002 8000 0004 4000 0008 2000"
 $"0010 1000 0020 0800 0040 0400 0080 0200"
 $"0100 0100 0200 0080 0400 0040 0800 0020"
 $"1000 0010 2000 0008 4000 3F04 82A8 4082"
 $"4288 8041 23A9 3022 12A1 C814 0AAE 7F8F"
 $"0402 3007 0201 0007 0100 8007 0080 6007"
 $"0040 1FE7 0020 021F 0010 0407 0008 0800"
 $"0004 1000 0002 2000 0001 4000 0000 8000";
 /* Mask */
 $"0001 0000 0003 8000 0007 C000 000F E000"
 $"001F F000 003F F800 007F FC00 00FF FE00"
 $"01FF FF00 03FF FF80 07FF FFC0 0FFF FFE0"
 $"1FFF FFF0 3FFF FFF8 7FFF FFFC FFFF FFFE"
 $"7FFF FFFF 3FFF FFFE 1FFF FFFC 0FFF FFFF"
 $"07FF FFFF 03FF FFFF 01FF FFFF 00FF FFFF"
 $"007F FFFF 003F FE1F 001F FC07 000F F800"
 $"0007 F000 0003 E000 0001 C000 0000 8000"
 }
};

resource 'MENU' (3) {
 3,/* Menu ID */
 textMenuProc, /* def proc */
 0x7FFFFFFD,
 enabled,
 "Edit",/* Menu title */
  {"Undo", noIcon, "Z", noMark, plain;
 "-", noIcon, noKey, noMark, plain;
 "Cut", noIcon, "X", noMark, plain;
 "Copy", noIcon, "C", noMark, plain;
 "Paste", noIcon, "V", noMark, plain;
 "Clear", noIcon, noKey, noMark, plain
 }
};

resource 'STR ' (128) {
 "This is my string"
};

resource 'STR#' (128) {
  {"One";
 "Two";
 "Three";
 "Four"
 }
};

resource 'WIND' (128) {
 {40, 80, 240, 400},
 documentProc,   /* window shape */
 visible,
 goAway,
 0,/* reference constant */
 "Untitled" /* Title */
};

Example 5: Rez input syntax for common resources

Finally, Written Output

Did you ever want to print a resource? Things were fine if you always defined your resources in terms of RMaker input files; you could just print these out. But RMaker quickly got tedious for dialog box item lists, and icons, among other things.

REdit was nice enough to decompile resources from the resource fork, but since REdit was designed to be a localization resource editor, not a developer's resource editor it, only understands a small subset of the commonly used resource types (see Resource Roundup, May 1986). For many of the resources that you most wanted to see, the output was just “No Format Specification Available.”

Now that MPW has come along, what do you do if you have floppies full of RMaker source files that are useless? Or, suppose you abandoned RMaker for ResEdit -- perhaps to support new resource types -- and now you want to convert to using MPW.

As we say here in California, NOOOO PROBLEM!!!! When you’re talking resources, DeRez is the second best resource utility I’ve ever seen. (ResEdit is still my all-around favorite.) It allows you to decompile any resource to a text file, and if you don’t like the output, you can modify the definition file to get it into the form you want.

Unlike executable code, compiled resources (a.k.a. the resource fork) contain nearly all the information that’s in the source file, and can be decompiled to recover that info. (MacNosy is very ingenious, but a disassembler cannot recover the original Pascal source, including variable names). About all you lose in decompiling resources is the indentation and comments.

In fact, Example 5 was originally written by DeRez, from a resource fork written by RMaker and modified by ResEdit! The comments and indentation were modified for compactness.

DeRez is real easy to use and, not suprisingly, the true inverse of Rez. The command

DeRez MDSsamp Types.r > MPWsamp.r

decompiles the resource fork of MDSsamp, using the definitions in Types.r, and writes the text output to MPWsamp.r. DeRez allows you to selectively include or ignore specific resource types or ID’s; for examples, you normally would want to

DeRez -skip CODE

Both options are a great improvement of REdit’s decompilation, since I normally found myself wanting to look at a specific resource type from several different files, such as the menus (to design my own “File” and “Edit” menus, for example.) That’s a piece of cake; just type:

DeRez -only MENU MacWrite Types.r

to have the menus inserted into the current document.

Of course, DeRez, like REdit, fails to provide a graphical record of those resources for which it would be appropriate, such as DITL’s or PICT’s. It would sure be nice if there were a tool to do that (is anyone listening out there?). For the time being, I take screen shots of the completed resources while in the application or one of the resource editors.

The Sleuth

When you need information on private parties, you call a private detective. If you want information on resources, then, naturally, it’s time to call on the Resource Detective, RezDet.

RezDet analyzes and validates resources far more rigorously than any other program, because that’s its sole function, to validate resources. This means it’s possible to manipulate a resource with DeRez or ResEdit, or for your program to use either the 64k ROM or 128k ROM resource manager. However, if RezDet takes a look, it may object to something the others have overlooked.

It enforces a canonical (standard) form on the resource map, header and data. Of course, it checks for invalid resource types, ID’s, names and attributes. It looks for extra or missing data, inconsistent sizes (between the map and the resource), duplicate resource ID’s or names.

It has several output modes. At one extreme, the “quiet” mode returns a success/failure status to the MPW shell. At the other extreme, the error messages are printed above a dump of the resource data. Other options allow inclusions of information on each resource; no options prints only error messages.

Example 6 shows the output of RezDet for the source shown in Example 5. The -show option is the least amount of information available (beyond the default print-out.)

RezDet -show MPWsamp

"MPWsamp":
Type 0x414C5254 'ALRT':
 There is one item of this type.
 Reference list offset is 90.
 ID #129:
 There is no resource name.
 Attributes (0x0):
 Data offset is 0.

Type 0x424E444C 'BNDL':
 There is one item of this type.
 Reference list offset is 102.
 ID #128:
 There is no resource name.
 Attributes (0x0):
 Data offset is 16.

Type 0x434E544C 'CNTL':
 There is one item of this type.
 Reference list offset is 114.
 ID #128:
 There is no resource name.
 Attributes (0x0):
 Data offset is 56.

Type 0x4449544C 'DITL':
 There is one item of this type.
 Reference list offset is 126.
 ID #128:
 There is no resource name.
 Attributes (0x0):
 Data offset is 87.

Type 0x444C4F47 'DLOG':
 There is one item of this type.
 Reference list offset is 138.
 ID #128:
 There is no resource name.
 Attributes (0x0):
 Data offset is 235.

Type 0x46524546 'FREF':
 There is one item of this type.
 Reference list offset is 150.
 ID #128:
 There is no resource name.
 Attributes (0x0):
 Data offset is 270.

Type 0x49434E23 'ICN#':
 There is one item of this type.
 Reference list offset is 162.
 ID #128:
 There is no resource name.
 Attributes (0x4): Preload
 Data offset is 281.

Type 0x4D454E55 'MENU':
 There is one item of this type.
 Reference list offset is 174.
 ID #3:
 There is no resource name.
 Attributes (0x0):
 Data offset is 541.

Type 0x53545220 'STR ':
 There is one item of this type.
 Reference list offset is 186.
 ID #128:
 There is no resource name.
 Attributes (0x0):
 Data offset is 617.

Type 0x53545223 'STR#':
 There is one item of this type.
 Reference list offset is 198.
 ID #128:
 There is no resource name.
 Attributes (0x0):
 Data offset is 639.

Type 0x57494E44 'WIND':
 There is one item of this type.
 Reference list offset is 210.
 ID #128:
 There is no resource name.
 Attributes (0x0):
 Data offset is 664.

The resource fork of MPWsamp appears to be OK.

Example 6: RezDet output for Example 5

Summary

There are certain aspects of MPW that many will find unattractive. RAM and disk space requirements would be my main complaints. This package cost me at least $1,000 in hardware, which makes it the second most expensive piece of software I’ve ever owned, next to my original copies MacWrite and MacPaint (which included a Macintosh 128 at no charge!)

[Note: plan on getting at least a 30 MB hard disk and preferably a 40 MB to support MPW. A twenty will fill up much too fast. -Ed]

However, there’s no doubt that the new tools for resource manipulation provided with MPW are more powerful and flexible than those they replace. For anyone who regularly uses resources, this is good news indeed.

Follow-up to “Be a Keyboard Sleuth!”

As many of you know by now, Volume IV of Inside Macintosh has been released, providing information on the changes between the original Inside Macintosh and features of the Macintosh Plus and the 128k ROM.

Those of you who read “Be A Keyboard Sleuth!” (Resource Roundup, August 1986) will understand why Apple added this passage to its revised “Macintosh User Interface Guidelines”:

To use arrow keys to make a selection, the user holds down Shift while pressing an arrow key. Application programs that depend (as TextEdit does) on the numeric keypad should not use these Shift-Arrow [sic] key combinations because the ASCII codes for the four Shift-arrow key combinations are the same as those for the keypad’s +, *, /, and = keys. If the use of Shift-arrow for making selections is more important to your application than the numeric keypad, the following paragraphs describe how it should work

For those of you who have forgotten about keyboard sleuthing, let me translate this for you:

1)There is a new standard for extending a selection using cursor keys;

2)There has been a standard mapping for entering symbols using the keypad;

3)Because the Macintosh Plus is compatible with the Lisa and optional Macintosh keypad, four keypad symbols share the same keycode as the shifted cursor keys, to the extent that the shifted cursor keys return the same ASCII codes as their keypad counterparts;

4)Therefore, standards 1) and 2) are inherently incompatible.

To resolve this problem, perhaps there could be yet another low-memory global (or even a bit) to provide a way to disable the emulation, e.g.

BrDmgKPad DC.B 1 ; 0 is Lisa-like keypad

Then applications that want to be able to tell the two apart can set the variable to non-zero, and reset it to zero prior to calling any desk accessories. Smart DA’s would save this value and restore it upon exit, setting it to 1 in the meantime.

Presumably a non brain-damaged keypad would return separate keycodes for cursor keys. At the very least, setting the flag would cause the Key2Trans routine to return a shifted arrow key with the same ASCII value as the unshifted key -- $1C (left), $1D (right), $1E (up), $1F(down) -- instead of $43, $42, $47 and $61 (“+*/=”.) The value of EventRecord.modifiers would, of course, include shiftKey.

By publishing this user interface standard as it sits, Apple is encouraging developers to implement keyboard selection using the ASCII value of the shifted arrow key from the original Lisa keypad, long after the Lisa is dead and buried. I’m not privvy to Apple’s sales figures, but my guess is that the number of Pluses sold at the end of 1986 will be 10 times the combined total of Lisas and optional keypads. Talk about the tail wagging the dog!

The tea leaf readers say that Apple will offer a Macintosh 68020-based engineering workstation and at least IBM PC compatibility in 1987. Since both IBM and DEC have each standardized on one keyboard for their terminals and PC’s, future Macs will have to support scads of distinct function keys. Perhaps the cursor-key-confusion can be resolved at that time.