Apple Macintosh before System 7
earlymacintosh.org
earlymacintosh.org
Looking through the sources, it was on one hand fun to marvel at the simplicity of the OS (and Mac Toolbox) from that era. I thought it was hard at the time though. Funny how hindsight (and lots and lots more experience) can change how you now see the past.
(I see so many cleaner styles of coding I could have adopted - have since adopted - when I look at my old sources.)
But I was amazed at how often the apps/OS crashed as I worked through trying to get them up and running within the emulators. At first I thought it was the emulator(s). But my next thought was ... maybe System 6 crashed all the time back then? I think so.
Example, I would run ResEdit (a development tool) and open a file that was also open in the IDE (THINK C or THINK Pascal). Crash!
Crashes required a reboot (often then requiring running Disk First Aid on the disk image and rebooting again...). I kind of see why Amiga guys laughed at us.
In fact I found a few bugs in sources from 35 years ago.
AmigaOS 1.0 was a disaster, 1.1 much better, 1.2 and 1.3 seldom if ever crashed.
2.0+ changed a lot... would be AmigaOS's own "system 7".
Of course, we still loved them. And the nostalgia, now.
The basic problem with those old home computer operating systems was the lack of memory protection. Any program could overwrite the memory of any other program, or even vital components of the operating system.
While memory protection was touted as a huge improvement for end users, its actual benefit was to developers. Just try to debugging memory issues in the application's own address space. Now try to imagine doing the same, where your only hints of a problem is someone else's code crashing because of memory you inadvertently overwrote.
Games especially seemed prone to messing things up when you exited, I think Arkanoid was particularly bad about it.
For those unfamiliar, Mac files of the era had two sections: a resource fork, and a data fork. Resources were structured chunks of information, like icons. You could open ResEdit and mod any app you liked.
I missed resource forks when they moved to the UNIX way in what's now macOS.
EDIT: I just checked the sources: it was mid 1993. Back then, a Macintosh Classic II would have been a common machine and shipped with 2 MB of RAM. Older machines often had only 1 MB of RAM.
Abused? That’s what it was designed to be. https://www.folklore.org/The_Grand_Unified_Model.html:
“Thankfully, I knew of a similar system in Smalltalk, an object-oriented virtual memory called OOZE that was designed by Ted Kaehler, that swapped objects in and out of main memory as required. This was my inspiration for the Resource Manager. Find out more about OOZE here”
You could mod Windows apps the same way (and at least one resource editor was also named ResEdit), yet the filesystem didn't provide multiple forks --- it was just a separate section in the binary.
In fact macOS apps are just a directory containing both the main binary and resources.
Later on, Windows NT gained resource forks. An early security flaw of IIS was that you could ask it to serve the DATA fork of any source file and see things like hard-coded credentials (because IIS would not execute the file, just serve its contents).
> In fact macOS apps are just a directory containing both the main binary and resources.
This is a much saner design decision, but it wouldn’t be possible before the file system got folders.
Forks caused all sorts of issues when you needed to transmit a file from one computer to another without using a floppy disk.
Similar to Windows 95 and the "illegal operation" box.
Which is one reason why Step 1 after unpacking the computer was to install the "Programmers Switch" to get access to the reset button.
Rebooting the machine was completely routine. And it wasn't particularly slow (in context, by todays standards, everything was slow, all of those machines were glacial), at least for the time. I don't recall having to ever really run Disk First Aid on anything though.
In fact, I remember making a "toy" that was a simple app that all it did was bring up the "Bomb box" (the infamous dialog with the sizzling bomb an reset button akin to the Blue Screen of Death). The detail was that if you moused to the Reset button in the dialog (which was, essentially an autonomic response for most Mac users), the Reset button would move away from the mouse. So, you "couldn't" hit the reset button.
There was another button, typically disabled (I think is said Resume or something, I can't recall -- it was always disabled), if you clicked that, it would "melt" the screen and exit the app, no harm done.
I spent a lot of meticulous time duplicating the dialog box and bomb icon. Run the program, note the box and icon, hit the interrupt button (on the Programmers Switch) to bring up the original, tweak, rinse and repeat.
Someone eventually uploaded it to the assorted BBSes. I found it in a book in a bookstore once.
8 pages of text filled up the RAM.
ETA: I wonder if anyone else still has that burned into their brains and knows what I’m talking about. Maybe I’m crazy.
Oh, that was you? I remember this program!
I'm not sure that's real. I don't recall that being a problem, and that's certainly something I did a lot back in the day.
At the same time, it took me a while to unlearn a kind of reflexive <command>-S muscle spasm that I think twitched about every 4 or 5 minutes.
https://vintageapple.org/inside_o/
My first computer was a Mac LC; I got it as a 10-year-old, and learned to program on it (and its replacement Centris 660AV) as a 12/13-year-old. At the time, the Inside Macintosh series was way too advanced for me; I lived on little Pascal game creation tutorials. It's interesting to look back on them now, as a professional programmer with ~25 years of experience. It actually looks pretty simple now. Also interesting to find that I can still read Pascal, even though I never used it professionally and haven't worked with it in 30+ years.
Vol. 6 of Inside Mac was too big though. No one is going to curl up on a sofa and read that book.
As programming documentation, they were way better than 99% of the after-thoughts that most companies published.
"Well, you'l have to find something else to like about Mac OS X," was my friend's reply.
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.
System .85! - https://apple.fandom.com/wiki/System_0.85 (December 4, 1983)
System 1 - https://apple.fandom.com/wiki/System_1
System 2 - https://apple.fandom.com/wiki/System_2.0
System 3 - https://apple.fandom.com/wiki/System_3
System 4 - https://apple.fandom.com/wiki/System_4
System 5 - https://apple.fandom.com/wiki/System_5
System 6 - https://apple.fandom.com/wiki/System_6 (April 1988)
Bonus round - Xerox Star UX (1982) - https://www.youtube.com/watch?v=Cn4vC80Pv6Q
https://vintageapple.org/inside_o/pdf/Inside_Macintosh_Volum...
“Calls to the Toolbox and Operating System via the trap dispatch table are implemented by means of the MC68000's "1010 emulator" trap. To issue such a call in assembly language, you use one of the trap macros defined in the macro files. When you assemble your program, the macro generates a trap word in the machine-language code. A trap word always begins with the hexadecimal digit $A (binary 1010); the rest of the word identifies the routine you're calling, along with some additional information pertaining to the call.”
And it probably was true that crashes in Microsoft products got patched in the system, while most other app developers did not get that courtesy.
The "software crashed expecting a co-processor" part doesn't make any sense either, you were always supposed to check if a co-processor was available. There was no big rug pull or anything, both the first models and some later models simply did not have co-processors. Developers were provided this information.
And the last two sentences seem completely unrelated to the prior ones, so I'm not really sure what they're trying to string together.
https://news.ycombinator.com/item?id=5322639
For your convenience, I'll quote the most relevant part of the story:
> One day, I was tracing through the OS code that handled a context switch and was surprised to find a bit of code that looked up the 32-bit creator code of the current application and compared it to 'WORD'. What the heck is this? I wondered. Turns out it was a hack added by the OS engineers at Apple to keep some other hacks in Microsoft Word working. If I recall correctly, they had to determine if Word was getting switched in or out so they could enable or disable the necessary hacks. So, in effect, they had a hack that would live-hack the OS to add hacks for Word's hacks and then live-unhack the hacks for everything else.
> I mean, when you're hacking the system to hack the system on behalf of someone who already hacked the system but for an older version of the system that's no longer there, now you're doing some hacking.
Shame we don't get the same care to documentation we used to.
And the locations will periodically change and/or disappear. Or it'll stay up and outdated information will be what search will find. And LLMs will read all of that and give you questionable output. Who needs manuals?
Desktop — IIci. Probably the best-looking of the 80s Macs, while at the same time large enough to give plenty of room for expansion.
Both of these had long lives thanks to upgrades, & both would be fun & good-looking revivals.