3 ms·
Reminds me of a startup I worked for in the 1990s. The C code base was organized into "units" (modules). Each unit allocated/destroyed its own data structures
by SeenNotHeard 3y ago
Reminds me of a startup I worked for in the 1990s. The C code base was organized into "units" (modules). Each unit allocated/destroyed its own data structures, but used the "ref" unit to return a reference (really, a handle) instead of a pointer. Each module used a "deref" function to convert the handle to a typed pointer for internal use.
ref used many of the tricks described in the above post, including an incrementing counter to catch stale handles.
All pointers were converted to handles in debug and testing builds, but in release builds ref simply returned the pointer as a handle, to avoid the performance penalty. As machines grew faster, there was talk of never turning off ref.
Side win: There was a unit called "xref" (external ref) which converted pointers to stable handles in all builds (debug and release). It was the same code, but not compiled out. External refs were used as network handles in the server's bespoke RPC protocol.
- OnlyMortal 3y agoThe old Mac used Handle so that it could move memory around as pressure mounted. In “some” ways, it’s a bit like a smart pointer as it’s a hook to allow the underlying system to “do things” in a hidden way.
- cpeterso 3y agoMicrosoft's Win16 memory allocator APIs (GlobalAlloc and LocalAlloc) also returned handles so the OS could move memory blocks to new addresses behind the scenes. Application code would need to call GlobalLock/Unlock APIs to acquire a temporary pointer to the memory block. The APIs still exist in Win32 and Win64 for backwards compatibility, but now they're thin wrappers around a more standard memory allocator. https://learn.microsoft.com/en-us/windows/win32/memory/comparing-memory-allocation-methods https://learn.microsoft.com/en-us/windows/win32/memory/compa...
- mmphosis 3y agoHistorically, I think there was an overlap of APIs between early Macintosh and early versions of Windows because Microsoft was porting their software. Microsoft released the first version of Excel for the Macintosh on September 30, 1985, and the first Windows version was 2.05 (to synchronize with the Macintosh version 2.2) on November 19, 1987. https://en.wikipedia.org/wiki/Microsoft_Excel#Early_history https://en.wikipedia.org/wiki/Microsoft_Excel#Early_history
- davepeck 3y agoIf anyone's curious, here's an old article about working with handles and the Macintosh memory manager: http://preserve.mactech.com/articles/develop/issue_02/Mem_Mgr_v006.html http://preserve.mactech.com/articles/develop/issue_02/Mem_Mg... (The article's examples are in Pascal, the original language of choice for the Mac.) —- Update: wow, Apple still has bits of the original Inside Macintosh books available online. Here’s a section on the memory manager, replete with discussions of the “A5 world” and handle methods (MoveHHI, etc.) in Pascal: https://developer.apple.com/library/archive/documentation/mac/pdf/Memory/Intro_to_Mem_Mgmt.pdf https://developer.apple.com/library/archive/documentation/ma...
- sroussey 3y agoOh man, that brings back memories! Inside Macintosh. Pascal. … The article got virtual memory wrong to a bit.. it got much better over the years and using relocatable handles fell by the wayside to more plain pointers.
- OnlyMortal 3y agoI was using MPW C, writing with 68k for performance pinch points, and malloc() was much faster than NewHandle() - faster than NewPtr() too. I guess there was some simple pre-allocated larger block that got parts handed out on demand. Not unlike a modern implementation. I still miss MPW Shell.
- natt941 3y agoI kinda miss the fun days of using addresses to physical memory. (Maybe I'm wrong but I've always assumed that explicit use of handles went out of fashion because virtual address lookup is, in effect, a handle.)
- nahuel0x 3y agoThis was used to avoid memory fragmentation: https://en.wikipedia.org/wiki/Classic_Mac_OS_memory_management https://en.wikipedia.org/wiki/Classic_Mac_OS_memory_manageme...