🚀 go-pugleaf

In article <43n5maINNep0@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
(Kazimir Kylheku) wrote:

> That all makes sense; but doesn't it strike you as strange that you have
> to jump through all these circles just to have a properly written
> Mac program? Under other operating systems, you just generate code
> that does what you want. Allocated memory stays at the same logical
> address.

And what happens in low-memory situations due to fragmenting on those same
systems?  The apps just quit, losing all of your work.  The handle
mechanism has nothing to do with CMT and everything to do with avoiding
low memory situations.  There are two ways to do it:  Do nothing (the Unix
way), and hope the situation doesn't occur very often, or do some form of
garbage collection.  Apple chose the latter.  Unix programmers write their
apps assuming an indefinite amount of virtual memory (just ask anyone who
tried to port CFront to a personal computer -- ugh), while Mac and PC
programmers assumed that memory is a very scarce resource.  Until
recently, that assumption was true.

> Nevin Liber keeps claiming that CMT systems are easier for the programmer
> because you don't have to mess around with things like semaphores. If
> this is true of the Mac, how do you explain all this memory handle
> locking business?

Low memory situations.  It has only been very recently that consumers
could afford enough RAM and disk space so that a programmer can ignore low
memory situations due to heap fragmentation.  It certainly wasn't
affordable in 1984, and since then backwards compatibility has been an
overriding consideration.
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799