Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!purdue!decwrl!decvax!dartvax!eleazar!earleh
From: earleh@eleazar.Dartmouth.EDU (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Goin' Crazy on a Mac, or, How I Love MPW "GlobalData"
Message-ID: <8816@eleazar.Dartmouth.EDU>
Date: 3 May 88 00:17:52 GMT
References: <4625@batcomputer.tn.cornell.edu>
Organization: Dartmouth College, Hanover, NH
Lines: 95
Summary: Aztec C advertises "unlimited data size and unlimited program size"

In article <4625@batcomputer.tn.cornell.edu>, garry@batcomputer.tn.cornell.edu 
	(Garry Wiegand) writes:
> 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...

You and everybody else!

> 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. 
> 
     I have before me an ad by Manx Software Systems which advertises
that their C compiler/development system is capable of "unlimited data
size and unlimited program size", including static and global areas.
If you get the "Developer System" you also get "MPW compatibility"
whatever that means. (Presumably source level compatibility, maybe even
the #include files have the same names!)  I have no experience with
this company, but for $299 for the Developer System, it certainly
seems that investigating their claims might be profitable.

     Personally, I think that if you are programming in C or any other
language which allows for dynamic memory allocation and data
structures, then you really do not need even 32k of global data.  Try
using malloc() to allocate space for your floating point arrays.  The
problem is possibly more one of program style than of the limits
imposed by MPW.  You might also consider putting string constants in a
resource; Apple provides the 'STR#' resource specifically for this
purpose.  This is no defense of Apple, I am merely trying to state
that maybe if you thought things over, you might find that you don't
need 32k of static space after all.  You might even consider using
"Handle"s to store your data and working with the Macintosh Memory
Manager!

> (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!)

     Unfortunately, this is true.  I have heard Macintosh users make
fun of the IBM PC and MSDOS for the 640k memory limit, but the size
limit for "small" model programs is 64k, not 32k, and most suppliers
of development systems support the large data model, where static data
can be as big as the machine can address.  Also, the debugger supplied
with MSDOS, "debug", sick as it is, can write out files and load a
program, features not even considered for "MacsBug" on the Macintosh.

     If you think Macintosh data structures are complicated, try
looking at some "X" code sometime!  Yuucchhh!  Try compiling a version
11 X program that you got from Charlie's BBS using the header files
that came with the version 11 X that came with your machine.  Chaos!
At least with Macintosh you get a single point of control for the data
structures that are used, even though nobody can agree on the size of
an "int" or the names of #include files, and there is serious doubt
sometimes that there is anybody home at the point of control.  (If you
want a real good laugh, take a look at Technical Note #88 "Hit
Signals" sometime:

SigBigA6	EQU	$FFFFFFFF	;maximum positive A6 value
...
	MOVE.L #SigBigA6,A6		;make A6 valid for Signal

Indeed!
)

     From the user's perspective, the Macintosh is a friendly computer
which is always responsive to his wishes through easy to use menus and
controls, and which requires no tiresome memorization of commands to
learn to use.  From the programmer's perspective, it is either a
challenge to program, or a never-ending nightmare of obscurity and
anti-support from the manufacturer.  Which one it is depends to some
extent on the attitude of the programmer involved, I think.  You have
to realize that the Macintosh is a user machine, and not a
programmer's machine.  On the bright side, the level at which you do
things on the Mac is usually so low, even compared with UNIX, that you
really have a remarkable degree of control over what your program can
do.
     
     I am primarilly a scientist, myself, and have been involved for
the past six months in trying to write a simulation program for use in
Pulsar research, using the Mac II.  I am beginning to realize that
having a beautiful user interface is maybe not so important for a
scientist as is the ability to get something done in a reasonable
amount of time, and with a reasonable amount of data security.  The
Macintosh certainly falls short in both of these areas.  I will accept
flames on all points except the last:  There is no data security for
your files on the Mac, and if you don't have three copies of every
file which you use, you are courting disaster.

     As a computer user, I heartedly recommend the Mac for terminal
emulation, word processing, spreadsheets, and most "user-type"
applications.  As a programmer and as a scientist, I cannot at this
time recommend it for anything other than as a boat anchor.
-- 
*********************************************************************
*Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755   *
*********************************************************************