MacOS 1.0 in 1984 used handles in order to allow the heap to be coalesced more easily (although locked handles and regular pointers often created islands). Given the first Mac had 128K RAM and no MMU, it was highly necessary at the time.
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".
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...
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.
True, but it was also your job as a developer to not be holding onto those pointers when the memory manager ran.
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.
Ideas are in a wheel, same ones always coming around again.