🚀 go-pugleaf

In article <43nlc8$sll@orion.cybercom.net> jerry@cybercom.net (Jerry Shekhel) writes:
> Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) 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.                                                    ^^^^^^^

Are all Mac programmers that uneducated? Do they know difference between
logical (virtual) and physical address?

> That's fine, but as your program executes, internal fragmentation builds up.
> Eventually you have a process whose data space is huge and full of holes.

Ugh. Objects have same _logical_ address, but nothing prevents
them from changing _physical_ address. In paged memory, continguous area
of logical memory can be mapped to many separate pieces of physical RAM,
so there is no fragmentation problem at all.

> The Mac approach allows the operating system to compact the heap, collecting
> all the free space into one large block.  This is very efficient memory-wise,
> but it requires additional CPU activity at runtime and additional effort on
> the part of the application developer.

Mac approach put memory virtualisation on behalf of application programmer.
Mac handle is, in fact, closest equivalent of logical address in 
virtual memory systems. In Mac, programmer must do virtual->physical
address translation by handle locking. VM systems do this in hardware,
and hardware is called MMU - Memory Management Unit. It automagically
takes care of all accesses to address, and automagically does locking/freeing.
If object is discarded, it calls operating system. This is called page fault.

Hardware implementation always are orders of magnitude faster than software
equivalents, and in this case hardware implementation makes software
several orders of magnitude simplier: programmer doesn't have to do
locking in any form.

> Internal fragmentation affects all programs regardless of the operating
> system on which they run.  

I never have meet internal fragmentation problems in unices and OS/2.
These problems are strictly specific to Mac and, in lesser extent, to Win16.
Demand-paged virtual memory systems, from VMS or IBM VM to Doom Operating 
System NEVER, repeat, NEVER suffer from any form of "internal fragmentation".

> UNIX systems ignore the problem and let the applications worry about their
> own heap management.  The OS itself provides only rudimentary facilities
> for expanding the heap.  On the other hand, UNIX provides very robust virtual
> memory capabilities, so most programs can get by using only the
> unsophisticated heap management of malloc() and related functions.

They can do it because internal fragmentation of heap is practically not
a problem under demand-paged VM. It might be a problem for a daemon
that runs for several months and actively uses malloc/free, and these
daemons might use advanced version of malloc or own allocations schemes.

> AmigaOS gives you the worst of all worlds.  It ignores both internal and
> external fragmentation problems, and offers no virtual memory.

I have limited experience with Amigas, so no comment.
From my perspective, they definitely have a problem here.

>: What if you don't do things right? With all these added complications, it's
>: not inconceivable that you accidentally dereference a pointer to a location
>: that no longer belongs to you and clobber some other program's data. Oops.
>: The whole system is spammed.

>The so-called complications are there for a reason.  Just because AmigaOS
>ignores certain problems doesn't mean they don't exist.

There is infinitely better solution than handles - virtual memory.
BTW, all modern Macs, AFAIK, have MMU. Newer apps could use it and
forget about handle crap - why Apple didn't provided way for this?
New applications wouldn't run on old Macs, but it is same situation
as with 680x0/PPC: new binaries do not run on old hardware, but they
are faster, smaller and more robust. IMHO, this is good tradeoff.

> You sound as if you've never developed a non-trivial application.

I participated in development of small application on Win16.
Win16 uses handles too - I wonder, why: 286 segments have
some form of VM. Officially handles are needed to maintain
compatibility with 8086 real-mode, but Win3.1 doesn't support
real mode at all, and most Windows programs won't fit to 640k.

If I did Windows, when implementing Standard mode I'd made
sure that all results of GlobalLock for same handle map to same
logical segment. On 286 it is very easy. Then combination of 
GlobalAlloc+GlobalLock would be a perfect equivalent of malloc(). 
Program relying on this wouldn't run in real mode, but I just would 
put a sticker on them: "Windows Standard Mode required". 

It would greatly simplify life of application programmer.

Handles are brain damage. It tooks a day to develop algorithm 
in 32-bit environment, and two days to put GlobalLock/GlobalUnlock 
in all appropriate places. Code increases in two/three times.
Programmer must be true masochist to enjoy handle-based
memory management.

> Fragmentation is a problem that affects programs no matter where they're
> running, be it MacOS, AmigaOS, UNIX, etc.  The fact that Apple provides a
> way to deal with it in the OS is not a bad thing.

Apple provides a kludge. 

Calling handles a way to fight fragmentation
is like calling nails a matherial for bed.
Some people can sleep on nails, but it hurts.

Cheers,
	Fat Brother.

Fatal Error: Couldn't enter Windows, use Doors.