Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!purdue!gatech!udel!rochester!cornell!batcomputer!garry
From: garry@batcomputer.tn.cornell.edu (Garry Wiegand)
Newsgroups: comp.sys.mac.programmer
Subject: Goin' Crazy on a Mac, or, How I Love MPW "GlobalData"
Message-ID: <4625@batcomputer.tn.cornell.edu>
Date: 30 Apr 88 21:11:47 GMT
Reply-To: garry@oak.cadif.cornell.edu
Organization: Cornell Engineering && Ithaca Software, Inc.
Lines: 56

We are attempting - and have been attempting for some time now - to
port our large 3D graphics subroutine library onto the Mac. The Mac
is driving us rapidly nuts. 

We have worked around the bugs in Quickdraw, the obscurities in the
documentation, the lack of a usable debugger, the solitary system
error message (a round black object with a fuse :-), and *some* of the
perversities of MPW/Aztec/Lightspeed/etc etc etc. We have not yet
succeeded in working around/through the bureaucracy at Apple so that
we can ask questions "officially". Now we've run into a wall, and we
could use some help. 

The MPW C compiler is not very good, but unfortunately it is Apple's
choice, so it has to be the primary focus of our Mac support. MPW C
has the custom of loading the A5 register with a pointer to all of
"global data" during program start-up. All accesses are then via a
15-bit offset to A5, which never changes.  ("Global data" consists of
everything that's not code and not dynamically allocated - global
variables, static variables, strings, and floating-point constants (12
bytes each!).)   The bottom line is that with MPW you can only ever
have 32K (2^15) of fixed data. Doesn't matter if your Mac has
megabytes and megabytes of memory; 32K is the static data limit. 

Question 1:
        Anybody know of any magic workarounds to this limit, short of
        damaging all of our source code? 
	
Question 2: 
	Has anyone heard any rumors that this MPW bug might be fixed
        sometime soon? (There's a rumored "3.0" release coming, but as
        far as we can tell a "32K" fix is not included in it.) 

Question 3: 
        We *might* be able to squeeze our own data into 32K, but the
        user program that links to our library would surely push
        things back over the limit. If we could separate the user's A5
        usage from our library's, then we might be OK. Has anyone ever
        gone through the exercise of segmenting a program into *multiple
        separate code resources* on the Mac?  (The system apparently
        does this all the time, but the details of the "message-
	passing" involved are obscure to us.) 

Any help would be greatly appreciated. 

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

PS: 
As much as I'm complaining about Apple's software, they're the only
PC/workstation company I've encountered so far that actually *cares*
about software, and thinks about how things *ought* to be done - they
don't just copy boring 15-year-old Unix ideas. "Inside the Mac" is 
interesting reading even if you never intend to use a Mac. 

(Good ideas unfortunately do not automatically make a system "programmer 
 friendly". "Ghetto" debugging, complicated data structures, no error 
 checking, and no error messages - Apple, you're a bunch of nitwits!)