3 ms·

from Apple Macintosh Segment Manager docs - https://developer.apple.com/library/archive/documentation/mac/pdf/Processes/Segment_Manager.pdf https://developer.ap

by canucker2016 3y ago

from Apple Macintosh Segment Manager docs - https://developer.apple.com/library/archive/documentation/mac/pdf/Processes/Segment_Manager.pdf https://developer.apple.com/library/archive/documentation/ma...: "Although needed code segments are loaded into memory automatically, it is your application’s responsibility to unload any segments that are not currently being used. The Segment Manager provides a single procedure, UnloadSeg, that you can call to unload a segment. To unload a segment is simply to unlock it. By unlocking unneeded segments, you allow them to be relocated or purged if necessary to accommodate a later memory-allocation request. Thus, using the Segment Manager to unload unneeded segments is one important aspect of an efficient memory-management policy."

duskwuff 3y ago
That bit of the documentation was... misguided. Relocating code segments was incompatible with many popular C runtimes (typically because CREL/DREL relocations were applied to the segment at load time, and there was no way to rerun that after a segment was moved), and was dangerous even if that wasn't the case (because stray references to the old location would often persist, e.g. as function pointers). Later on in the 68k Mac OS lifecycle, compilers figured out how to bypass the 32k segment limit, and would often compile the entire application to a single CODE resource, sometimes with auxiliary resources for embedded libraries. There was certainly no unloading those.
- canucker2016 3y ago
  Not misguided when the Macintosh was initially introduced with 128K of RAM. All the articles I've read about Apple Mac software development state that 68K assembly language and Pascal were used for software development. So the C compilers released later had bugs if they couldn't ignore/handle an UnloadSeg() call on one of their generated CODE segments. By the time I got into Mac development, THINK C and MPW C didn't seem to have any problems with CODE segments.

duskwuff 3y ago

That bit of the documentation was... misguided. Relocating code segments was incompatible with many popular C runtimes (typically because CREL/DREL relocations were applied to the segment at load time, and there was no way to rerun that after a segment was moved), and was dangerous even if that wasn't the case (because stray references to the old location would often persist, e.g. as function pointers). Later on in the 68k Mac OS lifecycle, compilers figured out how to bypass the 32k segment limit, and would often compile the entire application to a single CODE resource, sometimes with auxiliary resources for embedded libraries. There was certainly no unloading those.

canucker2016 3y ago
Not misguided when the Macintosh was initially introduced with 128K of RAM. All the articles I've read about Apple Mac software development state that 68K assembly language and Pascal were used for software development. So the C compilers released later had bugs if they couldn't ignore/handle an UnloadSeg() call on one of their generated CODE segments. By the time I got into Mac development, THINK C and MPW C didn't seem to have any problems with CODE segments.