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

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

#151

Post by grishka » Tue, Aug 29, 2023, 4:31 AM UTC

IIsi50MHz wrote: post #148

grishka wrote: post #124

Earlier quoted context omitted.

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.

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 exit…

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.

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

#152

Post by Wowfunhappy » Tue, Aug 29, 2023, 12:59 PM UTC

arcanemachiner wrote: post #42

Wowfunhappy wrote: post #32

Earlier quoted context omitted.

...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.

How about explicit depth levels, specified by asterisk count? e.g. '/*' and '*/' would match each other, '/**' and '**/' would match, and so on. That way, you would have full control of the depth of the comments, removing other comments wouldn't break the inner comments, etc. I do run into the same issue you're describing, so I think there's value in the idea.

The core idea here is that when I'm commenting out a block of code for testing, I don't really want to think about what is inside of it. So while I think this might help, I'd rather just have /* with one asterisk nest.

What I'm not sure of is whether there's an edge case I haven't thought of which would make this problematic.

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

#153

Post by IIsi50MHz » Tue, Aug 29, 2023, 1:59 PM UTC

grishka wrote: post #151

IIsi50MHz wrote: post #148

Earlier quoted context omitted.

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 exit…

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.

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?

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

#154

Post by khiqxj » Sat, Sep 02, 2023, 12:35 PM UTC

smoldesu wrote: post #69

khiqxj wrote: post #10

[flagged]

Even in 2006, people knew provoking Apple's ire was a dangerous game.

you cant sue someone for writing down what error messages that product can produce. you cant sue someone for reverse engineering their product (it has to have been done for an actual purpose like cracking or copying). you also cant sue someone for so happening to take teh shortcut of reverse engineering to obtain what they could have got just from using the product.