Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!ncar!boulder!sunybcs!bingvaxu!leah!itsgw!batcomputer!garry
From: garry@batcomputer.tn.cornell.edu (Garry Wiegand)
Newsgroups: comp.sys.mac.programmer
Subject: a resource which is a procedure
Message-ID: <4769@batcomputer.tn.cornell.edu>
Date: 12 May 88 00:46:34 GMT
Reply-To: garry@oak.cadif.cornell.edu
Organization: Cornell Engineering && Ithaca Software, Inc.
Lines: 32

Was: Goin' Crazy on a Mac, or, How I Love MPW "GlobalData"

I posted the original query, and, no, the code doesn't have any chunky arrays
that can be resourced out, and no, we can't switch to Aztec (this is an *object
library*, so it has to be used with whatever compiler the customers have
all picked. Ie, MPW.)  The "global data" mostly consists of billions
of floating-point constants (generated by the compiler) and small string
constants (from the original source) all scattered throughout our 60,000 
lines of source.

So: I'd like to ask again (perhaps a bit more clearly) a question I asked
before...  at several places Inside-the-Mac mentions "procedure resources". 
For example, on page I-363 it says 

   "The resource type for a menu definition procedure is 'MDEF'. The 
    resource data is simply the compiled or assembled code of the procedure."

It occurs to me that if we could load our complete library into some kind of
independent procedure resource like this, we wouldn't have to worry about the
user's program (that links to our library) making more contributions against
the 32K limit. (We'd still have to get our own stuff below 32 somehow.) Also,
our "library resource" could be loaded into the system file, and the user
executable images could get a lot smaller. Linking would be faster too. 

The Question: Does anyone know the details of how to construct a resource like
'MDEF' from C, and then how to call into it?

(sorry to take up bandwidth again, but procedure resources seem like they
ought to be an interesting idea. Object-oriented, and all that.)

garry wiegand   (garry@oak.cadif.cornell.edu - ARPA)
		(garry@crnlthry - BITNET)