Some of the error messages produced by Apple's MPW C compiler (2006)

Re:Some of the error messages produced by Apple's MPW C comp... by grishka on Monday August 28, 2023 @01:29AM (#37290119)

Not really. Classic Mac OS didn't support virtual memory so everything had to fit in RAM unless a program itself offloaded data it's not currently using to the disk. Modern OSes, however, all support swapping. Your compilation would continue, just much slower. To truly "run out of memory" on a modern computer, you have to fill up both the RAM and the disk.

[ Parent | on HN ]

Re:Some of the error messages produced by Apple's MPW C comp... by IIsi50MHz on Monday August 28, 2023 @05:22PM (#37300557)

Which version?

Regarding "everything had to fit in RAM": prior to real virtual memory, the Macintosh Resource Manager was capable of loading and unloading resources on the fly. Resources marked purgeable could be discarded when memory was needed. Code segments (another type of resource) could be loaded by automatically by the Segment Manager, but as you said would not unload until the application requested it or exited. INITs (system extensions) unloaded all code after initialisation by default (requiring extra steps to keep anything in RAM).

Virtual memory was built-in by System 7 (and I think available on supported hardware via 3rd party utilities earlier?).

[ Parent | on HN ]

Re:Some of the error messages produced by Apple's MPW C comp... by grishka on Tuesday August 29, 2023 @12:31AM (#37303589)

Unloading code and resources is easy — you already have them on the disk. Unloading runtime state though, that's the hard part. I've never used classic Mac OS when it was current, much less haven't developed for it, so no idea how often, if at all, apps used temporary files to work on more data than can fit in memory.

[ Parent | on HN ]

Re:Some of the error messages produced by Apple's MPW C comp... by IIsi50MHz on Tuesday August 29, 2023 @09:59AM (#37308071)

Ok, fair. Mac resources, including CODE resources, could be modified by the running program and unless marked as read-only were saved to disk by the relevant Manager before unloading. Photoshop was noted for its unusual use of disk, which was said to work like a virtual memory system.

Due to lack of protected memory, a few programs, especially on the earliest machines, with the least memory, 'abused' the display buffer by using it as RAM. Of course, this corrupted the screen, but it would all just be drawn again as soon as the program yielded time to the OS. Back then, only one user program could be running at a time, and it mostly had the screen to itself, so why not use it to copy floppies with less disc swapping?

[ Parent | on HN ]