I went through the process of gathering old sources for the games I wrote in that era. Using 68K Mac emulators (BasiliskII for example) I was able to also get the compilers and other dev tools of the era such that I could compile and run from source.
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.
> But I was amazed at how often the apps/OS crashed
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.
The explanation I understood was that invalid expressions like “Finder” evaluated to an odd number. Since jumping to an odd address is disallowed on the older 68K machines, the default failure behavior was to exit the current application. People used to claim that the code above was more reliable, but maybe this was superstitious: in practice everything is unreliable once you’ve encountered a serious bug on a system without memory protection.
I just did a search and found collected PDFs of all of the Inside Macintosh volumes. (For those who don't remember, these were technical manuals on how to develop hardware peripherals and write software for the Macintosh.)
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.
I remain convinced that the 1990s rewrite of Inside Macintosh (which can be found here on your site: https://vintageapple.org/inside_r/) was the best documentation Apple ever produced.
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.
I used to use ResEdit to make new fonts. The fonts were fully defined as bitmaps in the resource fork; pop open the System file in ResEdit and you could make whatever you wanted. Turned in all my school papers during middle school in a font of my own design.
Confession: Back in the day, before Macs had a real virtual memory system, I abused the Resource Manager and a file's resource fork to serve as a crude VM for an object management library I created so that I could write apps that used more C++ objects than would fit in memory. It was a hack, but it worked surprisingly well.
“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”
I think the Resource Manager was designed with the "objects" in mind being understood to be an application's assets, such as code, graphics, menus, text, and so on. My abuse was to extend this to arbitrary, dynamically allocated blobs so that an app could, for example, scan thousands of files and store each file's metadata in virtual memory, way beyond what would fit in RAM.
This would have been in the early 1990s, I'd guess.
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.
Ha, I worked in a computer lab a student assistant and used to modify the Netware for Mac client on some of the tech staff we worked for. I remember swapping the logout and login commands on our boss's computer.
Resourcerer had better templates for lots of common GUI elements, but system resources were complete in ResEdit. Don't forget rez and derez tools for the list.
I missed resource forks when they moved to the UNIX way in what's now macOS.
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.
I remember Borland’s resource editor. I themed my VGA.DRV file quite extensively.
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.
> 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.
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.
Yes. It had an ugly UI and preemptive multitasking, but it didn't have memory protection and -- unlike MultiFinder -- didn't clean up after apps for certain resources, so you'd eventually need to reboot to get those resources back even if your system remained stable.
I remember there being "recoverable" errors in later versions of the OS. But if you got a "Guru Meditation" you were almost always done. With newer machines (68020+ w/MMU) you could protect the first page of memory which helped ("Enforcer" was the name of the program, I think.)
Netscape was crashy everywhere. I finally switched to IE in ~2000 despite being a die-hard Microsoft hater, because DoubleClick shipped some code that would hang Netscape and as a result the whole Internet broke.
Yeah, the main issue was the lack of memory protection on Mac so the crashes could take down the whole machine. I switched to NT4 though that had drawbacks of its own.
I remember my Mac Plus and Classic being very stable - but I think that had more to do with the testing that the applications went through than anything to do with MacOS.
I'll try to repro. I think with System 7 and on a lot of improvements were made to the OS (things like an Extensions manager comes to mind). Perhaps we're remembering those better days.
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.
Pre MacOS X did indeed crash all the time. I learned to only use one application at a time. It would still crash a couple of times a day, requiring a restart. On the other hand it was snappy and simple, in a way modern OSs just aren’t.
True. When a friend of mine and I showed my wife OS X when the first beta came around, I remember when I went to shut down the machine the wife said she didn't like how OS X took to quit (older Mac OS would shut down near instantly).
"Well, you'l have to find something else to like about Mac OS X," was my friend's reply.
System 7/apps would crash from time to time. I think we just had lower standards then. IIRC Macs prior to OS X didn’t separate one process’ memory from another?
Windows 95 was a big step forward though because it had actual process isolation and preemptive multitasking. While it wasn't very stable compared to Linux or NT, for the most part an application crash wouldn't bring down the whole machine the way it typically happened on classic Mac OS or Windows 3.1.
Interesting: ROM code was accessed through ANNN ("A-line") traps. Then they started using F-line traps for co-processors. Then in the proliferation of models targeting education, they started putting out advanced CPU's without co-processors, so lots of software crashed expecting a co-processor. But of course if Word crashed, they'd talk about monkey-patching the OS pending the next release. Apple folks thought MS tailored their software to break the Mac, and thereby gain the upper hand in licensing talks.
As a programmer writing OS-level utility software for Macs back in the day, I stumbled across one of the MS-preservation hacks in Mac OS. I wrote about it here on Hacker News twelve years ago:
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.
“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.”
It is written very strangely. It's not exactly like they reached the decision to use F-line traps for co-processors, I'm pretty sure F-line traps were designated by Motorola for co-processors, and A-line traps were free for use for OS and Toolbox trap instructions.
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.
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?
Which vintage -era mac is your favorite? The Macintosh IIfx is one of the more interesting ones because for the time it was so expensive and powerful. At the time it could render 3d graphics.
Compact — SE/30. Amazingly expandable & powerful, while at the same time almost being portable given its size. Perhaps an era equivalent, except for having a monitor, for the new Minis.
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.
I actually owned a prototype Mac II that I got from Apple when it was pre-production. The case was ... mostly missing. I borrowed a pre production color monitor and got our app to show graphics in color (I think 6 colors was all it could do) but it was amazing to see.
The SE was just small enough that I could cart it in the bag that was available to/from my campus office. I recall being fond of the IIcx but couldn’t afford one even once I graduated.
I also love the Quadras, but they wouldn't count as pre-System-7 since they shipped with 7.0.1. Though I'm honestly more nostalgic for System 7 than '80s Macs because 7's what I grew up on. Mine's a Quadra 700, and I love how much computer it fits into what little footprint: https://i.imgur.com/snIBxeF.jpeg
Why Apple not open this system?
It would have been enough to let people use the old system 6. Apple never did localization for Polish and many other languages. It didn't add USB, etc. It could have been done today.
Awesome thank you for finding that. I was just recently lamenting that O'Reilly had stopped putting obsolete books on a download page so I could not point people who wanted a look at another of my books could find it without ebaying hardcopy.
This website has been around forever and I appreciate it now as much as I did back when I first stumbled across it as I was learning about Mac emulation.
I went through the process of gathering old sources for the games I wrote in that era. Using 68K Mac emulators (BasiliskII for example) I was able to also get the compilers and other dev tools of the era such that I could compile and run from source.
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.
> But I was amazed at how often the apps/OS crashed
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.
Remeber to save your 10 page paper before you get through the 8th page.
8 pages of text filled up the RAM.
I remember that app! I think the version I had was named “Sexplosion” to encourage people to click on it.
Yea, I think someone named it "Hot Sex". That wasn't me :).
SM 0 A9F4 G 0 ;)
ETA: I wonder if anyone else still has that burned into their brains and knows what I’m talking about. Maybe I’m crazy.
'G Finder' worked, too, surprisingly.
The explanation I understood was that invalid expressions like “Finder” evaluated to an odd number. Since jumping to an odd address is disallowed on the older 68K machines, the default failure behavior was to exit the current application. People used to claim that the code above was more reliable, but maybe this was superstitious: in practice everything is unreliable once you’ve encountered a serious bug on a system without memory protection.
> the Reset button would move away from the mouse
Oh, that was you? I remember this program!
LOL yes that was a good one.. seen here in California
I just did a search and found collected PDFs of all of the Inside Macintosh volumes. (For those who don't remember, these were technical manuals on how to develop hardware peripherals and write software for the Macintosh.)
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.
I remain convinced that the 1990s rewrite of Inside Macintosh (which can be found here on your site: https://vintageapple.org/inside_r/) was the best documentation Apple ever produced.
Apple really wrote amazing and comprehensive documentation. I wish they would do so today.
I've culled most of my computer books as I've moved, but I'll hold on to my Inside Mac volumes.
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.
ResEdit was awesome!
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.
Favorite hack: taking goofy pictures of my friends faces and ResEditing them into SimCity 2k in place of various departmental advisors.
I used to use ResEdit to make new fonts. The fonts were fully defined as bitmaps in the resource fork; pop open the System file in ResEdit and you could make whatever you wanted. Turned in all my school papers during middle school in a font of my own design.
Confession: Back in the day, before Macs had a real virtual memory system, I abused the Resource Manager and a file's resource fork to serve as a crude VM for an object management library I created so that I could write apps that used more C++ objects than would fit in memory. It was a hack, but it worked surprisingly well.
> I abused the Resource Manager and a file's resource fork to serve as a crude VM
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”
I think the Resource Manager was designed with the "objects" in mind being understood to be an application's assets, such as code, graphics, menus, text, and so on. My abuse was to extend this to arbitrary, dynamically allocated blobs so that an app could, for example, scan thousands of files and store each file's metadata in virtual memory, way beyond what would fit in RAM.
How long ago? The resource fork was limited to 16 MB (it used 24-bit pointers in some places), so you can't have been swapping that much data out.
This would have been in the early 1990s, I'd guess.
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.
Ha, I worked in a computer lab a student assistant and used to modify the Netware for Mac client on some of the tech staff we worked for. I remember swapping the logout and login commands on our boss's computer.
Resourcerer had better templates for lots of common GUI elements, but system resources were complete in ResEdit. Don't forget rez and derez tools for the list.
rez and derez are still in OS X (command line).
I missed resource forks when they moved to the UNIX way in what's now macOS.
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.
I remember Borland’s resource editor. I themed my VGA.DRV file quite extensively.
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.
> 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.
Rest assured the Amiga crashed plenty too.
Yeah, but the whole machine needing to be rebooted?
Yes.
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.
Yes. It had an ugly UI and preemptive multitasking, but it didn't have memory protection and -- unlike MultiFinder -- didn't clean up after apps for certain resources, so you'd eventually need to reboot to get those resources back even if your system remained stable.
The UI in Amiga OS 2.0 was a huge improvement... It felt like night and day! Earlier versions were definitely pretty bad looking.
They were.
Of course, we still loved them. And the nostalgia, now.
I remember there being "recoverable" errors in later versions of the OS. But if you got a "Guru Meditation" you were almost always done. With newer machines (68020+ w/MMU) you could protect the first page of memory which helped ("Enforcer" was the name of the program, I think.)
Often times auto-rebooting and showing a guru meditation.
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".
I don't remember Glider crashing at all but running anything really big and complicated like Netscape it was only a matter of time.
Netscape was always crashy on classic MacOS. Most other app software, and even games, were relatively stable.
Netscape was crashy everywhere. I finally switched to IE in ~2000 despite being a die-hard Microsoft hater, because DoubleClick shipped some code that would hang Netscape and as a result the whole Internet broke.
Yeah, the main issue was the lack of memory protection on Mac so the crashes could take down the whole machine. I switched to NT4 though that had drawbacks of its own.
Flash plugin was another frequent crasher, I remember most of my browser problems being Flash and not the browser itself
I've spent a good bit of time over the last few years playing with a Plus and an SE/30, and I'd say yeah they just crashed all the goddamn time.
Games especially seemed prone to messing things up when you exited, I think Arkanoid was particularly bad about it.
I remember my Mac Plus and Classic being very stable - but I think that had more to do with the testing that the applications went through than anything to do with MacOS.
> 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!
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.
I'll try to repro. I think with System 7 and on a lot of improvements were made to the OS (things like an Extensions manager comes to mind). Perhaps we're remembering those better days.
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.
Pre MacOS X did indeed crash all the time. I learned to only use one application at a time. It would still crash a couple of times a day, requiring a restart. On the other hand it was snappy and simple, in a way modern OSs just aren’t.
True. When a friend of mine and I showed my wife OS X when the first beta came around, I remember when I went to shut down the machine the wife said she didn't like how OS X took to quit (older Mac OS would shut down near instantly).
"Well, you'l have to find something else to like about Mac OS X," was my friend's reply.
Early versions of OS/X weren't that stable either, I remember it crashing every time I pulled an already ejected USB key.
System 7/apps would crash from time to time. I think we just had lower standards then. IIRC Macs prior to OS X didn’t separate one process’ memory from another?
Indeed. I lost several essays before figuring that Tetris and MacWrite Pro wouldn’t coexist.
The crash dialog box with the bomb icon was a pretty common encounter as I recall it.
Similar to Windows 95 and the "illegal operation" box.
Windows 95 was a big step forward though because it had actual process isolation and preemptive multitasking. While it wasn't very stable compared to Linux or NT, for the most part an application crash wouldn't bring down the whole machine the way it typically happened on classic Mac OS or Windows 3.1.
I still remember back then we joked that Macintosh stood for: Most Applications Crash If Not The Operating System Hangs. :)
FYI if interested in visuals for the earlier system OS
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
Don't forget Apple's Lisa:
https://arstechnica.com/gadgets/2023/01/revisiting-apples-il...
https://www.folklore.org/Busy_Being_Born.html
Interesting: ROM code was accessed through ANNN ("A-line") traps. Then they started using F-line traps for co-processors. Then in the proliferation of models targeting education, they started putting out advanced CPU's without co-processors, so lots of software crashed expecting a co-processor. But of course if Word crashed, they'd talk about monkey-patching the OS pending the next release. Apple folks thought MS tailored their software to break the Mac, and thereby gain the upper hand in licensing talks.
As a programmer writing OS-level utility software for Macs back in the day, I stumbled across one of the MS-preservation hacks in Mac OS. I wrote about it here on Hacker News twelve years ago:
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.
Is this an AI response? It's essentially gibberish after the first two sentences.
It all makes sense to me v(._. )v
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.”
It is written very strangely. It's not exactly like they reached the decision to use F-line traps for co-processors, I'm pretty sure F-line traps were designated by Motorola for co-processors, and A-line traps were free for use for OS and Toolbox trap instructions.
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.
It mostly makes sense to me. "Advanced CPUs" should have been "advanced models" (The Mac LC) missing coprocessors.
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.
I had a Mac Plus and those owners manuals were a work of art.
Shame we don't get the same care to documentation we used to.
It'll just be online!
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?
Is this the same manual listed here https://www.computinghistory.org.uk/det/66123/Macintosh-Plus... ?
Whilst more the personality side, found https://www.folklore.org a fun read of the early times at Apple.
Which vintage -era mac is your favorite? The Macintosh IIfx is one of the more interesting ones because for the time it was so expensive and powerful. At the time it could render 3d graphics.
Compact — SE/30. Amazingly expandable & powerful, while at the same time almost being portable given its size. Perhaps an era equivalent, except for having a monitor, for the new Minis.
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.
The SE/30 was the first Mac I had on my desk at work, it was a lovely machine.
I actually owned a prototype Mac II that I got from Apple when it was pre-production. The case was ... mostly missing. I borrowed a pre production color monitor and got our app to show graphics in color (I think 6 colors was all it could do) but it was amazing to see.
The SE was just small enough that I could cart it in the bag that was available to/from my campus office. I recall being fond of the IIcx but couldn’t afford one even once I graduated.
I like my Quadra 950.
I also love the Quadras, but they wouldn't count as pre-System-7 since they shipped with 7.0.1. Though I'm honestly more nostalgic for System 7 than '80s Macs because 7's what I grew up on. Mine's a Quadra 700, and I love how much computer it fits into what little footprint: https://i.imgur.com/snIBxeF.jpeg
Why Apple not open this system? It would have been enough to let people use the old system 6. Apple never did localization for Polish and many other languages. It didn't add USB, etc. It could have been done today.
Anyone have a copy of this: https://www.amazon.com/Programming-Techniques-Macintosh-Zigu...
https://annas-archive.org/md5/c79594767ff7d952edc0c65682d5ac...
Awesome thank you for finding that. I was just recently lamenting that O'Reilly had stopped putting obsolete books on a download page so I could not point people who wanted a look at another of my books could find it without ebaying hardcopy.
This website has been around forever and I appreciate it now as much as I did back when I first stumbled across it as I was learning about Mac emulation.
Flashback to the days of doing system upgrades over Floppy Disk.