Those were not the same kind of handles AFAIK. This particular article is about pooling objects of the same time AND using indices (which the articles calls handles) to reference them. They aren't handles by any definition I've heard of in the past. AFAIK the definition of a handle is an opaque reference to some object, when you want to use the object you ask the handle for the object's actual address being aware that the address is only useful for some defined period (like having to call ptr = acquire(handle) ... do work with p ... release(handle) (p is now not valid).

Handles by that definition have the usage the can be moved in memory to clear up fragmentation but they have none of the other benefits this particular post is talking about. Those benefits only come from their specific implementation, not from the idea of "handles".

Microsoft Windows did the same:

https://devblogs.microsoft.com/oldnewthing/20041104-00/?p=37...

In later versions, heap memory handles were even implemented in Intel x86 hardware:

https://devblogs.microsoft.com/oldnewthing/20041105-00/?p=37...

Aren't *nix file descriptors kind of an OS "handle"?... Okay, I'm hiding in case anyone sees this comment and lobs a criticism my way ;).

No need to hide, same thought occurred to me reading the article too.

Of course you mean System 1, not MacOS 1.0. Handles were used all the way through System 7, last released in 1997. Perhaps by then it was more about the legacy than the need. Don't know the physical limits, but a Quadra 950 could support 256MB RAM and more through VM (ramdisk), and of course these later gen machines did have MMUs.

In ye olden days, addressing was probably physical, so being non-multi-tasking ensured the safety of using handles, ie if used properly. IOW the system process was free to clean up the heap and manipulate your pointers b/c your app would only yield at specific points where you aren't holding onto a dereferenced handle.

> Handles were used all the way through System 7

Handles continued to be used all the way through Mac OS 9, as they were used by a ton of critical Toolbox APIs like the Resource Manager. A vestigal version even existed in Mac OS X -- handles still existed in Carbon, but I'm not sure they would ever be relocated by the system like they were previously.

> of course these later gen machines did have MMUs.

They did, but it was only used to simulate a system with more physical memory. Every process still saw the same view of a single "flat" memory space.

> the system process was free to clean up the heap and manipulate your pointers b/c your app would only yield at specific points where you aren't holding onto a dereferenced handle.

True, but it was also your job as a developer to not be holding onto those pointers when the memory manager ran.

Oh right, my modern brain went to the wrong name.

Yes, and could be a huge pain to develop in. We always wrapped the handles in library calls to assert them, which minimized problems.

Ideas are in a wheel, same ones always coming around again.

Came here to say this. Referencing objects through handles allowed much better memory management on a primitive OS like System 3.