🚀 go-pugleaf

In article <501@psu-cs.UUCP> smethers@psu-cs.UUCP (Paul Smethers) writes:
>I agree that the Mac Memory Manager is probably the best way to go when
>implementing programs on the Macintosh, but by using it you restrict your
>portability to other machines...

In the specific case of the Macintosh Toolbox Memory Manager I would
choose the strategy of implementing compatible memory management on a
porting target. For other parts of a program, like its on-disk
document structure, I would make it exactly the same on all machines.

>                                       ...  All computers are now
>converging to windowing systems, and even though you write for the Mac
>now, you never know when you need the portability.  The windowing portability
>is not a easy problem, but the memory portability is almost free because
>of the standards with unix libraries (malloc type routines).  The same
>goes for file i/o (printf).

You bet windowing isn't easy to make portable. I believe the best you
can do at this point is make a program structure that can be
implemented in several window systems. For instance, in many
applications it makes sense to think of each window as a view on the
data. Porting involves implementing the views in a different windowing
and graphics environment.

I would not rely on malloc, the printf/scanf function, and least of
all, fread/fwrite to enhance portability. In the Macintosh environment
they just add bulk to the program without yielding benefits above the
availble Toolbox calls. In Unix environments, printf is growing
irrelevent in the face of much more powerful Postscript-based
formatting. (For instance, dialog boxes programmed to substitute
strings at the client end of a session.)

Hoping to design for easy portability is a grail quest. And Murphy's
law dictates that once easy portability is attained, the program (and
likely its implementation language as well) will be obsolete. Software
is so perishable it can hardly be called an asset. The best that can
be hoped for is that algorthims, techniques, and the engineering
talent that makes programs can be preserved from one product
generation to the next.

-Zigurd
-- 
------------------------------------------------------------------------
Zigurd Mednieks		   MURSU Corporation		(617)424-0146
			   25 Exeter Street
			   Boston, MA 02116