I don't think I'll start pre-installing System 7 since most of my customers are using Mac OS 9 (and the domain is os9.shop!), but you could certainly get a machine from me with Mac OS 9 and install System 7 yourself if you so desire.
My customers have included a lot of real businesses running legacy software who want the fastest, least intrusive, and least energy intensive Mac OS 9 desktop machine they can buy. I've sold to dentists, veterinarians, museums, and auto repair stores. You'd be amazed how many people are running Classic Mac software in 2025.
I use only 128 GB mSATA cards from reputable brands.
I always do the following:
- Boot from the Mac OS 9 Lives 9.2.2 image (v9 of the image) by CD
- Wipe the SSD using Disk Utilities 2.1
- Restore from the CD
I will say this fails perhaps 1 out of 20 times. Hard to say how often this is an actual hardware failure versus some kind of incompatibility with the mSATA SSD since I do use a range of brands. I am always using the same adapters.
I had fun with hypercard on MacOS 9. At work, even. The boss was into rapid prototyping, and I cooked up some damn productive stacks in a hurry.
It runs on the Cube and under OS 9 emulation on the new stuff.
Hypercard scripters did cool things that most users don't do today. And without those monster data centers.
I was the Program Manager, and as usual we were very tightly constrained for time, and in the era of golden master DVDs that had to be ready to distribute at JavaOne in the Moscone Centre... Hard decisions had to be made. The team decided to work on more important features, and drop the configuration wizard from 2.0. Then I did what everyone knows is a no good, very bad, terrible thing. And although I got away with it that time, it's still a no good very bad, terrible thing:
I took my work computer home for the weekend and fired up a HyperCard "compiler" called Runtime Revolution that could make executables for Windows and Unix. Come Monday morning, we had a shippable configuration wizard. Leadership blew its top, because one of their values was, "We're a Java shop, which means we use Java to write Java tools." And after I left the company, they rewrote the configuration wizard in Java Swing.
https://en.wikipedia.org/wiki/LiveCode_(company)
To this day I consider firing up Electron and a complete React framework for simple tools to be a "Turing Tarpit," a place where absolutely anything you imagine is possible, but nothing of interest (in the domain of simple tools) is easy.
Yeah, when a coworker and I showed my wife the first OS X preview, she was alarmed at how long it took to shut down (I mean System 7 shut down like you just kicked the cord out). "You'll have to find something else to like about it," was my coworker's response.
And to be sure, there was/is a lot to like about OS X.
But, probably because of the lack of a kernel, etc., System 7 sits somewhere in that nether/middle region on our personal computer journey. It's rich library of functions (the Toolbox) set it apart from machines before it that might have instead had a handful of ASSM routines you could "CALL" in BASIC to switch display modes, clear the screen, etc. But, as Amiga owners often reminded the Mac community in the day, no "true" preemptive multitasking…
I should say too, regarding programming, these days your ability to write safe, threaded code is probably the highest virtue to strive for, hardest to perfect — at least for me (so hard to wrap my head around). It seems to separate the hacks (in the negative sense) from the programming gods. I think wistfully of those simpler times when managing memory well, handling error returned from the system API gracefully were the only hurdles.
"You can’t simply add a lock here, because this function can be called while the lock is already held. Taking the same lock again would cause a deadlock…"
"The way you've implemented semaphores can still allow a potential race condition. No, I have no idea how we can test that scenario, with the unit tests it may still only happen once in a million runs—or only on certain hardware…"
(Since I have retired I confess my memory of those hair-pulling days are getting fuzzier—thankfully.)
Why is eveything so slow on new MacOS?
Most Mac software I use (I don’t use Chrome) starts quickly because the dependencies (shared libraries) are already loaded. Chrome seems to have its own little universe of dependencies which aren’t shared and so have to be loaded on startup. This is the same reason Office 365 apps are so slow.
My M4 MacBook Pro loads a wide range of apps - including many that have no Chromium code at all in them - noticeably slower than exactly the same app on a 4 year old Ryzen laptop running Linux, despite being approximately twice as fast at running single-threaded code, having a faster SSD, and maybe 5x the memory bandwidth.
Once they're loaded they're fine, so it's not a big deal for the day to day, but if you swap between systems regularly it does give macOS the impression of being slow and lumbering.
Disabling Gatekeeper helps but even then it's still slower. Is it APFS, the macOS I/O system, the dynamic linker, the virtual memory system, or something else? I dunno. One of these days it'll bother me enough to run some tests.
People used to make YouTube videos of their Mac opening 15 different programs in 4/5 seconds
Now, my Apple Silicon MacBook Air is very, very fast but at times it takes like 8-9 seconds to open a browser again.
It still works fine today, though I had install Linux on it to keep it up to date.
In any case, Chrome opens quickly on my Mac Mini, under a second when I launch it from clicking its icon in my task bar or from spotlight (which is my normal way of starting apps). When Chrome is idle with no windows, opening chrome seems even faster, almost instant.
This made me curious so I tried opening some Apple apps, and they appear to open about the same speed as Chrome.
Gui applications like Chrome or Keynote can be opened from a terminal command line using the open command so I tried timing this:
$ time open /Applications/Google\ Chrome.app
Our work laptops have antivirus and other verification turned on which impose a 4-16x penalty on IO.
The cpu, memory, and ssd are blazing fast. Unfortunately they are hamstrung by bad software configuration.
I have seen people suggesting that it's because of app signature checks choking on Internet slowness, but 1. those are cached, so the second run should be faster, and in non-networked instances the speed is unchanged, and 2. I don't believe those were even implemented back in 2002 when I got my iMac G4, and it was likewise far quicker in Linux than in OS X.
At the time (2002), I joked that it was because the computer was running two operating systems at once: NeXTSTEP and FreeBSD.
There absolutely were animations e.g. when closing a Finder window, but they were much lighter weight. As far as I'm concerned System 7 was probably the zenith.
So yeah Apple had tacked on vestigial multi-user support, an automatic system update mechanism, USB support, etc., etc. but underneath it was still the same old single user, cooperative multitasked, no memory protection OS as its predecessors. Unlike OSX, MacOS 9 (like 7 and 8 before it) still relied on the Toolbox which was a mishmash of m68k and ppc code.
To be clear, Win98 was a garbage fire of an OS (when it came to stability); which makes it so much worse that Mac OS 8-9 were so bad.
Maybe not on a Pentium, but once you hit 192MB of RAM and some 500 MHz P3/AMD k7, NT based OSes were tons better.
You only realized that upon opening a dozen of IE windows. W98, even SE, will sweat. 2k will fly.
On single tasks, such as near realtime multimedia ones, w98 would be better, such as emulators/games or video players with single thread decoders. On multiprocessing/threading, w98 crawled against W2K even under p4's and 256MB of RAM.
On the other hand on my mobile Firefox I wait seemingly a half second each time I long press a link, because there is an animation that zooms a context menu. It does not zoom from the link, which could be justified maybe, but always in the same place in the center of the screen. This animation is meaningless and thus wasteful.
If you had no X11 acceleration (xvesa for instance), that mode was magnitudes faster than watching your whole browser window repaint on a resize lasting more than 3 seconds on a Pentium.
It still irritates me that command + N does a new window, not a new folder. I wouldn’t even have used that shortcut much, as I was a kid and it’s been 25 years.
Ah, classic Python. Removing features [0] and breaking perfectly working software just because the feature is old, ugly, and not widely used.
Who knows, maybe someone would want to run it on vintage Mac hardware?
Nonetheless, this is an impressive accomplishment.
[1] https://cdn.preterhuman.net/texts/computing/apple_hardware_d...
The powercity models were interesting, because they came out after Apple revoked Motorola's clone license. A German company, ComJet, bought up the boards and sold unlicensed clones cheap. Case was slightly different, but otherwise they corresponded to StarMax models (fairly certain they were identical but may have been last revision boards).
Apple Cobra Open Firmware CHRP 1.1 B3 built on 08/18/97 at 13:04:24
Copyright Apple Computer 1994,1996,1997
Copyright IBM Corporation 1996
All rights reserved.
ok
0 > dev / ls
ff82ec18: /cpus
ff82ee08: /PowerPC,604e@0
ff82f600: /chosen
ff82f750: /memory@0
ff82f8d8: /memory-controller@fec00000
ff82f9d8: /openprom
ff82fab8: /rom@ff000000
ff82ff48: /boot-rom@fff00000
ff830060: /options
ff830828: /aliases
ff830c78: /packages
ff830d00: /deblocker
ff8314c8: /disk-label
ff832090: /obp-tftp
ff835db8: /mac-parts
ff836578: /mac-files
ff837de0: /fat-files
ff839700: /iso-9660-files
ff83a148: /bootinfo-loader
ff83b7d0: /xcoff-loader
ff83c060: /pe-loader
ff83c7d0: /elf-loader
ff83da18: /terminal-emulator
ff83dab0: /rtas
ff83dc70: /pci@80000000
ff83ff38: /isa@b
ff8414e0: /nvram@i74
ff841ad0: /rtc@i70
ff842500: /parallel@i378
ff842988: /serial@i3f8
ff843020: /serial@i2f8
ff8436b8: /sound@i534
ff850288: /8042@i60
ff8515f8: /keyboard@0
ff854b88: /mouse@1
ff8554c0: /fdc@i3f0
ff858730: /disk@1
ff85bac0: /op-panel@i808
ff85bba0: /pwr-mgmt@i82a
ff85bed8: /timer@i40
ff85c070: /interrupt-controller@i20
ff85c250: /dma-controller@i0
ff85c738: /pci-ide@b,1
ff85d028: /ide@0
ff85db78: /ide@1
ff85e6c8: /cdrom@0
ff862e60: /mac-io@d
ff863468: /scsi@10000
ff865298: /disk
ff8660c8: /tape
ff8671b8: /adb@11000
ff867cb0: /keyboard@2
ff8685a0: /mouse@3
ff8687c0: /escc-legacy@12000
ff8689b8: /ch-a@12002
ff868b08: /ch-b@12000
ff868c58: /escc@13000
ff868e40: /ch-a@13020
ff869500: /ch-b@13000
ff869bc0: /via@16000
ff869cb0: /interrupt-controller@40000
ff869e70: /cirrus@e
ff86e2c8: /pci1022,2000@f
ok
0 >
The Motorola Yellowknife board seems remarkably similar to this system, as well as the IBM Long Trail system (albeit with Long Trail using a VLSI Golden Gate versus a MPC106 memory controller). Both of them use W83C553 southbridges and PC87307 Super I/O controllers.
The architecture is kind of weird, but the schematics on NXP's website can probably elucidate a bit more on the system's design.
Maybe in the future I won't have to make that choice! I'd much rather dual boot OS 9 off a different partition, but that hasn't been supported on the 1-1.25GHz models (Thanks Steve...) and no one has gotten it working properly. Maybe now it will be possible! A man can dream...
I remember clicking and waiting.
And not just for the reasons that animations were sparse, they also never blocked input, so for example if you could see where a new element would appear you could click there DURING the animation and start eg typing and no input would be lost meaning that apps you used every day and became accustomed to would just zip past at light speed because there were no do-wait do-wait pipeline.
Truth be told, I do have a suspicion that some folks (possibly - some folks close to Avie or other former NeXT seniors post-acquisition) have noticed that with dynamic loading, hard drive speed, and ubiquitous dynamic dispatch of ObjC OSX would just be extremely, extremely slow. So they probably conjured a scheme to show fancy animations to people and wooing everyone with visual effects to conceal that a bit. Looney town theory, I know, but I do wonder. Rhapsody was also perceptually very slow, and probably not for animations.
There were also quite a few tricks used all the way from the dithering/blitting optimizations on the early Macs. For example, if you can blit a dotted rect for a window being dragged instead of buffering the entire window, everything underneath, the shadow mask - and then doing the shadow compositing and the window compositing on every redraw - you can save a ton of cycles.
You could very well have do-wait-do-wait loops when custom text compositing or layout was involved and not thoroughly optimized - like in early versions of InDesign, for instance - but it was the exception rather than the rule.
Done exactly this myself to conceal ugly inconsistent lags - I don’t think it is that uncommon an idea.
How would you have done it?
I still remember the day teenage me got an Amiga 500 with a whopping 512K of RAM, and witnessed the power of multitasking, way back in 1988.
And certainly was very not a problem on PowerPC which TFA is about.
Also not sure how you can say the 68000 "barely has interrupts" I don't even know what you're on about.
MacOS was broken because Jobs forced it to be that way after he was kicked off the Lisa team. Which had a preemptive multitasking operating system on the 68000.
Space constraints were certainly limiting on the earlier models, but later ones were plenty capable. Apple itself shipped a fully multitasking, memory protected OS for various 68k Mac models.
By the late 80s, the only reason the Macintosh system was still single-tasking with no protected memory was compatibility with existing apps, and massive technical debt.
I run OS 9 on my lamp iMac G4 but now I want to try 7.6.1!
++ BBEdit
The 180 or 200MHz 603e with 16k L1 cache in that Performa 6400 wasn't slow by any stretch, but it probably didn't have L2 cache. Coupled with the gradual transition to PPC native code of the OS and apps, these machines were often a little mismatched to expectations and realities of the code.
Meanwhile that PowerTower had a 604e with 32/32k L1 and 1MB L2 cache. That was a fast flier with a superscalar and out of order pipeline more comparable to the Pentium Pro and PII.
Consumers didn't grok cycle efficiency, pipeline depth, or branch prediction miss pipeline stall latency.
I emulated Mac OS 7 under XP times, and i was impressed that you could get far faster speeds emulating the M68k (and partially the PPC) compared to Intel X86 without any hardware accelerating chip (IntelVT) or kernel modules trapping X86 instructions running it at native speeds. I mean, PPC and M68k chips where much easier to emulate than X86 on itself.
On software, Classic Mac users can just resort to IRC and Gopher clients and visit the public https://bitlbee.org IRC servers in order to connect 'modern' accounts and being proxied to a Mac IRC client. And for Gopher, you have gopher://hngopher.com, gopher://magical.fish and the like. Sadly you don't have an easy TLS library as Amiga users have (AmiSSL) where even modern web can work on it (and IRC over TLS, Gemini...).
Altough... if Amiga m68k emulators run fast with the Rosetta like tech for PPC... you would just fire up Workbench and then AmiSSL. Crude, but it would work. If not, here in the Apple subdir you can get, maybe, some TLS enabled browsers:
gopher://bitreich.org/1/lawn
and
gopher://happymacs.ddns.net/1Vintage-Mac-Software-Archive
MacSSL:
https://github.com/demoniccode12/MacSSL
Usenet will work fine without any TLS, and there's tons of content out there.
Wish someone would try to create native MacOS classic on x86 hardware.
There are so many Unix or Linux ABI compatible kernels like the recent Moss written in rust.
Apple worked on this themselves - and then they canned it.
https://lowendmac.com/2014/star-trek-apples-first-mac-os-on-...
But if you are some software preserver, having a libre option to run legacy media it's always good for historical reasons. I am a daily libre software user but I emulate ancient machines with propietary stuff just for curiosity. As it not a personal computing device I find it fine. It's just an historical toy and not my computing device. And, well, if you want to create libre engines for old Mac games (ScummVM, SDL ports...), for sure you need to at least emulate the old OSes and run the propietary game in order to compare the output and correctness.
Also, it already exists "Mac" for x86. It was Rhapsody DR2 and it could run Classic Mac software and NeXT one too. It was like a blend of these two. OSX it's like NeXT Step concept 2.0, with few traces of Mac Classic. Qemu will run it fine.
https://lunduke.substack.com/p/hands-on-with-1998s-rhapsody-...
"Unfortunately [the Blue Box] was only available on PowerPC versions of Rhapsody"
Another option is Advanced Mac Substitute. It doesn't run everything, but what it does run it runs really well. One of my goals is that you can use a 68K Mac application (e.g. MacPaint) as part of your personal computing workflow, if you wish.
Edit, ah, both are similar.
Would not even need to be binary compatible. Source compatible API would be enough.
Rhapsody DR2 is more like Classic Mac than any current MacOS.
At least the NeXTStep part; not the Mac GUI (Carbon?) one.
Now, if I can just get a nice portable with:
- largish OLED
- current gen Wacom EMR digitizer support
- decent battery life
running Linux, I can get off the Windows update treadmill....
For some reason european science was full of old school Mac users.
The rest of our shop was Solaris on SPARC/x86 and we had our own custom tool chain that crunched the data, but the sequencer itself was run by a Mac.
From 1999 or so forward the next generation of machines were Windows.