Earlier quoted context omitted.
Maybe this is it? http://telcontar.net/Screenshots/worldwidewonk/Amazon-404-eh...
Thanks to both of you for this heartwarming bit. How do you go about finding something like that?
Some of the error messages produced by Apple's MPW C compiler (2006)
141–150 of 154 posts
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#142> "...And the lord said, 'lo, there shall only be case or default labels inside a switch statement'" Did it seriously not let you have a goto label inside a switch?! This seems like an odd restriction, as all 3 are the same kind of thing.
They're different enough that you can't goto a case or default label.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#143"a typedef name was a complete surprise to me at this point in your program" I've seen this list so many times and this one makes me laugh out loud every single time.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#144Earlier quoted context omitted.
Void pointers refer to anything and nothing. They are everything and all encompassing. What is pointed to by the void pointer could be what you want or it could be another universe. Dereferencing a void pointer has no meaning. The compiler can do anything it wants because it doesn't know how to interpret the memory. It could give you the correct thing, it could warp a civilization in from a distant planet, or it coul…
Has any civilization been warped in already?
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#145Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#146Earlier quoted context omitted.
It's a joke (clearly not a very good one) based on my experience that when Apple first offered only 8GB of RAM on the first ASi Macs, everyone's response was that Apple Silicon can simply store more data in the same amount of memory or something. Back when I used macOS on Intel, 16GB was relatively comfortable, but I can't imagine that switching to ARM would magically halve memory requirements. (Yes, the Intel Mac ha…
The AS memory compression is better as it's hardware accelerated. IIRC Windows doesn't like to overcommit memory and its allocation calls will actually fail instead, but I don't remember the details.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#147Earlier quoted context omitted.
The AS memory compression is better as it's hardware accelerated. IIRC Windows doesn't like to overcommit memory and its allocation calls will actually fail instead, but I don't remember the details.
zswap supports pretty much any cryptographic accelerator. Accelerating memory compression isn't really a new or particularly "better" innovation.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#148> "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer" Ah, the old times when one could purchase a RAM upgrade or upgrade RAM after buying a computer. Now this would be: "Symbol table full - fatal heap error; please go buy a new Mac with more RAM"
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.
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?).
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#149Earlier quoted context omitted.
I see this sentiment again and again, but the Windows 95 experience I remember included frequent spinning hourglasses, blue screens of death from faulty drivers, everything grinding to a halt when memory is near exhaustion or files are being copied between disks, tons of third party applications (and even Microsoft applications, like Office) that disregarded the Windows UI standards, constantly having to run CHKDSK a…
Thing is, our computers are magnitudes of orders faster than 20-30 years ago. Why isn't our software orders of magnitudes faster? I'll settle for just 10 times faster. If you take software from 20 years ago, and run it on modern hardware, it will be instant in most operations.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#150Earlier quoted context omitted.
Well, the bloat has made many programs slower than they could be. Software is eating up the advances we get in hardware. Modern Word 365 is not any faster than Word 95 on a Pentium 66 in normal use. That is a ~100MHz computer with maybe 16MB RAM, and a rotating hard drive. Bloat making software bigger will in many cases also make it slower. Also, the UX on Windows 95 was consistent and easy to learn. Now, much softwa…
I see this sentiment again and again, but the Windows 95 experience I remember included frequent spinning hourglasses, blue screens of death from faulty drivers, everything grinding to a halt when memory is near exhaustion or files are being copied between disks, tons of third party applications (and even Microsoft applications, like Office) that disregarded the Windows UI standards, constantly having to run CHKDSK a…