Hacker News new | past | comments | ask | show | jobs | submit login

> But I was amazed at how often the apps/OS crashed

Early microcomputer systems usually didn't have memory protection hardware, but they also were typically single-user, single-app systems.

Cramming a GUI and OS into 64 or 128 KB (!) of RAM (and some ROM) meant that apps didn't have a lot of memory to work with; even to this day apps behave poorly when they run out of memory - we just have a ton of it now, as well as virtual memory, so things tend to get slow before they crash.

As I understand it, Apple's Pascal compiler supported range checks but developers typically disabled them for speed and code size, eventually switching to C, which didn't have range checks at all. Failing a range check would result in a graceful system bomb box rather than an ungraceful one. I also think that the the Mac (following the the Apple II) kept important data in low memory, making null pointer errors (perhaps a failed memory allocation) particularly destructive.

It was such a big deal when Apple finally implemented system-wide memory protection that they added an app crash dialog box that said "The application SomeApp quit unexpectedly. Mac OS X and other applications are not affected" – which Steve Jobs demonstrated by running a "bomb" app while playing a video in quicktime player.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: