Xref: utzoo comp.sys.next:5792 comp.sys.mac:52479
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!mit-eddie!rutgers!okstate!minich
From: minich@a.cs.okstate.edu (MINICH ROBERT JOHN)
Newsgroups: comp.sys.next,comp.sys.mac
Subject: Re: NeXT Review;Quite a machine, but not a Mac
Message-ID: <5522@okstate.UUCP>
Date: 6 Apr 90 19:46:49 GMT
References: <6453@blake.acs.washington.edu>
Organization: Oklahoma State Univ., Stillwater
Lines: 53

From article <6453@blake.acs.washington.edu>, by mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin):
> 
> I just remembered another "feature" about the Mac, which reminds me
> why I intend never again to do software development on the Mac
> platform.  Like MS-DOS, the Mac operating system splits memory into
> 64K segment; no object may be larger than that.  So, if you need a
> 100,000 character string, you have to split it into chunks.
 
  Well, either you haven't looked real close or you are just remembering
something from someone who heard that it was said... There is no problem
on the Mac with big chunks of data. That is what the Memory Manager is
great at! Just ask for a chunk of arbitrary size, and if it can be
provided, you've got it. What I think has gotten into your head
somewhere is the limit on the size of single objects in the resource
_file_ (32K) where other considerations are at work. This is not a real
big prob IMHO, and I certainly prefer to have the Resource Manager
rather than writing my own code to attempt something analagous.

> Also, there's no memory mapping, so system memory management is done
> by shuffling.  The way they do this is by a bizarre system of double-
> indirect pointers.  Although this is OK for memory-tight systems, it's
> a lot of work for the programmer to keep track and for large memory
> systems this is slower than allocating enough memory for the
> application to begin with and shuffling it to a larger chunk with a
> single base register than making all those double-indirect references.
 
  Yes, the Mac's memory management does "shuffling" and uses double
indirection, but the concept is very clean in use. And if you ask
anyone who uses big apps regularly, you'll find that all computers are
"memory-tight systems". :-)  No, it's NOT a lot of work for programmers
to keep track of things with handles. (IMHO, again.) Just make sure
there is something on the end of a handle before you use it, and your
fine. About the base register BS... if the Mac's memory was segmented by
hardware into chunks, this _might_ be worthwhile, but it isn't. Now, if
you mean you want a base register for a big chunk you get back from the
memory manager to divy up yourself, that's fine and you can do that if
you want. (Of course, some assembly required. :-) 
  I think you'd do well to talk with someone who has actually written
for the Mac about these "details" before you go to far in putting them
down. There are definite limitations, but not at all the ones you
describe. 

> I guess this was all for CP/M compatibility.  ;-)

  naaaw, they did it for clone protection! :^)

Robert Minich
Oklahoma State University

minich@a.cs.okstate.edu

-- 
Robert Minich