4 ms·

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). Give

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.

valuearb 6y ago
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.
greggman3 6y ago
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".
jiveturkey 6y ago
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.
- news_to_me 6y ago
  > 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.
- duskwuff 6y ago
  > 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.
- coldcode 6y ago
  Oh right, my modern brain went to the wrong name.
User23 6y ago
Came here to say this. Referencing objects through handles allowed much better memory management on a primitive OS like System 3.
jlokier 6y ago
Microsoft Windows did the same: https://devblogs.microsoft.com/oldnewthing/20041104-00/?p=37393 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=37383 https://devblogs.microsoft.com/oldnewthing/20041105-00/?p=37...
octetta 6y ago
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 ;).
- javajammer 6y ago
  No need to hide, same thought occurred to me reading the article too.

valuearb 6y ago

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.

greggman3 6y ago

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".

jiveturkey 6y ago

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.

news_to_me 6y ago
> 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.
duskwuff 6y ago
> 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.
coldcode 6y ago
Oh right, my modern brain went to the wrong name.

User23 6y ago

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

jlokier 6y ago

Microsoft Windows did the same: https://devblogs.microsoft.com/oldnewthing/20041104-00/?p=37393 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=37383 https://devblogs.microsoft.com/oldnewthing/20041105-00/?p=37...

octetta 6y ago

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 ;).

javajammer 6y ago
No need to hide, same thought occurred to me reading the article too.