Xref: utzoo comp.sys.mac.misc:13077 comp.windows.ms:13739
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!aero-c!Aero.org!doner
From: doner@Aero.org (John Doner)
Newsgroups: comp.sys.mac.misc,comp.windows.ms
Subject: Re: Mac Vs. Windows? (sorry)
Message-ID: <1991Jun12.154934.20965@aero.org>
Date: 12 Jun 91 15:49:34 GMT
References: <0E010021.e0mxxc@gla-aux.uucp> <1991Jun4.154854.19649@dbase.A-T.COM> <56nD02AQ08cd01@JUTS.ccc.amdahl.com> <1991Jun12.055711.21457@cs.yale.edu> <1991Jun12.152813.20074@leland.Stanford.EDU>
Sender: news@aero.org
Organization: The Aerospace Corporation
Lines: 24

In article <1991Jun12.152813.20074@leland.Stanford.EDU>, aaron@jessica.stanford.edu (Aaron Wallace) writes: 
|> 
|> I've never actually programmed a Mac (life does have it's small blessings!),
|> but I remember that my girlfriend once had do for a Pascal class.  I remember
|> her having to worry about arranging static data into segments and getting
|> segment too large errors.  I've read elsewhere that, lovely as the linear
|> address space is, Apple went through all kinds of hoops and backflips to
|> simulate a segmented memory system on the Mac.

What looks like a segmented memory system to some is mainly just a compiler
limitation.  They use 16-bit integers as array subscripts, so arrays get limited
to 2^16.  They always generate branches using the 16-bit offset instructions,
instead of the 32-bit ones, so CODE segments get limited to 32K.  None of this
is Apple's doing, or intrinsic to the hardware or the Mac OS.

One limitation that is in the OS is the jump table size of 32K.  This limits the
number of external (i.e., inter-CODE-resource) references accordingly.  Not much
of a problem, except with MacApp.  (Does System 7 fix this?)

Actually, it's hard to fault the compiler writers.  It seemed so reasonable at
the time.  But with today's cheap memory, it's a bad idea to build those limitations
into the compilers.

John Doner