[A] doomed attempt to create a modern Mac operating system
You have to admire their pluck and persistence. They still haven't given up yet.
Apple buried Copland 30 years ago. Now the failed OS boots in a browser
Thirty years after Apple abandoned Copland, its doomed attempt to create a modern Mac operating system, a new emulator lets you try the final developer build in your browser. Copland was intended to replace Apple's System 7 with a PowerPC-native operating system built around a microkernel, protected memory, and preemptive …
-
-
Monday 28th September 2026 07:17 GMT abend0c4
Re: s(miles) ahead of Microslop
If a previous, equally doomed, iteration of Apple development overreach had come to pass, PCs and Macs might both have been running the same OS.
-
-
Monday 28th September 2026 09:00 GMT Charlie Clark
Re: "SimpleText is unable to run because of a serious error"
Much as I liked NextStep, I can't help thinking that BeOS might have been the better fit for the areas where MacOS was being used, especially multimedia. The hard work on a kernel that could run on different architectures had been done and the integration with the GUI was, and probably still is, the best. Next had DisplayPostscript and better POSIX support on its side and better networking.
However, a bit like the original OS for IBM, I suspect technical merits weren't the deciding factor.
-
Monday 28th September 2026 10:10 GMT JamesWRW
Re: "SimpleText is unable to run because of a serious error"
NeXT had a portable SMP kernel too. More importantly they had a product that had real world (if admittedly niche) usage. BeOS was a tech demo. A very good one, but it was incomplete. For one it didn't have multiuser support. NeXT also had a very nice development environment. Yes, you had to learn to love Objective-C and square brackets, but once you were past that hurdle it provided a mature and pleasant means of developing apps.
-
Tuesday 29th September 2026 15:26 GMT Charlie Clark
Re: "SimpleText is unable to run because of a serious error"
As I said, I don't think the technical stuff was that important. FWIW BeOS also had a very nice development environment and everyone I ever spoke with said the API was a joy to work with, and learning APIs is often much more work than one language or another.. Multiuser devices were definitely not common at the time and, even today, I can think of lots of multimedia setups where that would never have mattered, whereas the responsive UI was a world leader for years. The BeFS also let developers hand off many common tasks to the file system such as tagging and indexing.
-
Monday 28th September 2026 10:41 GMT Liam Proven
Re: "SimpleText is unable to run because of a serious error"
> Much as I liked NextStep, I can't help thinking that BeOS might have been the better fit
I admire the visual design of NeXTstep. I've only played with it in emulators, and found it clunky in actual use.
I admire the visual design of BeOS, and have used both real BeOS and Haiku extensively in both VMs and on bare metal, and I find it not only looks good but works very well.
When NeXT faced design decisions that had a Mac-like or un-Mac-like choice, they chose un-Mac-like to avoid getting sued. OS X reverted all of these and is a better UI as a result.
BeOS used whatever they liked and it has Mac-like influences and PC-like influences and in other places goes its own way. I like the result a lot.
So, overall, for me, BeOS wins here.
--> **BUT!** <--
NeXT had 2 big things Be didn't, and some smaller ones.
1. NeXT had state-of-the-art industry-beating development tools.
2. NeXT had Steve Jobs, and whatever his many personality flaws, he had real vision.
Also:
• NeXT had a standards-based core OS which drew heavily on what we now call FOSS, meaning it avoided reinventing a lot of wheels by adopting BSD code. It meant it delivered more with a small team, and it freed that small team to work hard on the innovative bits of the GUI and so on.
• NeXT had a design that wasn't CPU-dependent and things like fat binaries to support that.
Be redid the whole thing from scratch and was proud of it.
As a result BeOS was tiny and clean and fast... but yes, functionally poor in places.
I love BeOS. I hugely like Haiku.
(Haiku has spent years putting back a tonne of the Unix stuff Be carefully removed. It's more versatile as a result but bigger and slower and more complex.)
I honestly think if Apple had bought Be instead, Apple would be a fading memory by now.
No dev tools, no compelling message for developers, no vision for bold tech innovation. The BeBox was proud of its profusion of ports and expansion, especially the GeekPort.1
Instead, Jobs oversaw the iMac: no ports, no removablew writable media. USB and Ethernet and a modem: lower than the absolute minimum for 1998, and yet, it was enough.
Apple did the right thing. Apple was saved by the iMac and iPod and that revenue bought them time to make OS X work. Then, once it worked, it proved its versatility by enabling the iPhone and iPad and iTunes Store and other actual commercial products people wanted and bought and kept buying because they're good at what they do and you can't expand them.
In an ideal alternate universe, Apple bought NeXT but Acorn merged with Be. Be never did an x86 version and instead with Acorn made world-beating multimedia workstations with 2, then 4, then 8 Arm CPUs and no cooling fans. It also made gorgeous sexy superthin laptops with no fans that lasted days on a charge: the M1 MacBooks but 20 years earlier.
But if I am daydreaming, then what happened 5Y earlier is that Apple made Möbius a product, unified the Mac and Apple II lines in the early 1990s and then with investment in Acorn it made faster Arms earlier.
But how Apple fixed MacOS then, I don't know. Maybe the NeXT deal still happens?
-
Monday 28th September 2026 11:17 GMT Dan 55
Re: "SimpleText is unable to run because of a serious error"
Apple needed to buy Jobs' project management skills more than anything else. They already had a NeXT, it was called A/UX, but they'd spent years tying themselves in knots with collabs in IBM (Power, Taligent).
And in an example of history repeating itself, ex-Apple people moved to Google where they couldn't get Fuchsia out the door in any meaningful way and Google decided to can it and merge Android and ChromeOS instead.
-
Monday 28th September 2026 16:55 GMT Liam Proven
Re: "SimpleText is unable to run because of a serious error"
> Apple needed to buy Jobs' project management skills more than anything else.
I am honestly not sure he had any. I think he mainly just shouted at people until they made stuff work.
Yes, sure, he had strong ideas about design, elegance, clarity, simplicity, design, and much more. "Great artists _ship_" and so on. But project management? I think that was for his minions.
> They already had a NeXT, it was called A/UX, but they'd spent years tying themselves in knots with collabs in IBM (Power, Taligent).
No, really not.
A/UX was not NeXTstep by any means.
A/UX was a box-ticking exercise, carried to Old Apple extremes. ("Old Apple" here meaning pre-Return Of Jobs.)
The US military stipulated it would only buy computer systems that were POSIX-compatible. So, Apple made a Mac Unix.
Well, actually, Apple paid Unisoft to do it. Unisoft is still around:
http://unisoft.com/
V1 was less impressive; the cool stuff appeared in A/UX 2 and 3.
But the problem is that the 68030 A/UX does its clever stuff by integrating with the original 68000 MacOS. It's a 680x0 Unix calling 680x0 MacOS routines, and in v2 & v3 running a version of the 680x0 MacOS GUI.
Apple made PowerPC MacOS work by writing a tiny bootable nanokernel:
https://en.wikipedia.org/wiki/Mac_OS_nanokernel
... which emulated 680x0 (specifically 68040EC) code very fast. So the prototype PowerMac booted a 68040 emulator, then that booted MacOS. Then, broadly speaking and oversimplifying, they profiled the 680x0 MacOS, worked out which were the most performance-critical parts, and rewrote them in PowerPC code.
The clever thing about the nanokernel is that it allowed 680x0 code to make calls to PowerPC code, and it enabled PowerPC in a very limited way to make calls into 680x0 code. Microsoft called this sort of thing "thunking" but Microsoft was talking about letting x86-16 code call into x86-32 code. That's not quite the same.
There is more detail on the nanokernel out there. It's never been released as FOSS. For me it's one of the most impressive bits of OS code from the 1990s.
I used to have a little indicator in my menu bar that showed a green light when running PowerPC code and a red light for 680x0 code. When I ran an old 680x0 app, it stayed red 99% of the time and just very occasionally blinked green. When I ran a native PowerPC app, it was mostly green and occasionally blinked red when it called into OS code that hadn't been rewritten or converted. (I have looked for this and can find no trace of it on the modern Web, sadly.)
If you were in MacOS, that indicated stayed red and occasionally blinked briefly green. Most of the OS remained 680x0 code.
That approach was what Apple needed to boot MacOS on an alien CPU and keep most of users' existing apps working.
And it wouldn't work with A/UX.
If A/UX had run on the nanokernel then its performance would have sucked. That approach wouldn't work at all.
If A/UX had been rebuilt for PowerPC then it would have looked like any other Unix because all the clever Apple OS integration stuff would have stopped working. So it would have looked like any other Unix: no Finder, no MacOS apps, no MacOS integration.
If Apple ported all the MacOS bits to PowerPC the project would have been 100x bigger and more difficult and Copland shows that it wasn't able to handle such big tasks anyway.
If Apple rewrote classic MacOS for PowerPC then all the native classic apps would have stopped working. In other words,
[a] it's doubtful Apple could have done a full native PowerPC A/UX. Inform lacked the skills; it was a 680x0 specialist.
[b] if it had done that, it would have lost the single most appealing aspect of A/UX -- the integration with classic MacOS apps.
I used to think A/UX was the answer the company missed, much as you are saying, but some former Apple techies on ClassicCmp.org disabused me. Join the lists and search the archives; you can probably find the threads from a decade ago.
But in summary, no, A/UX was not the answer.
What Apple needed was not a 680x0 Unix with very close 680x0 MacOS integration. That was a millstone.
What it needed was a Unix which natively understood different CPU architectures, was portable and had already been ported, which had a built-in system for multi-architecture binaries. NeXT had that, and TBH I can't think of anyone else at the time which did have that.
Only Sun came close. Ellen Hancock argued for buying or licensing Solaris. Sun had versions of Solaris for x86, and 68000, and SPARC. (And later, briefly, for POWER.) But Sun didn't have any of this fancy CPU emulation stuff. It sold these OSes at around the same time, and while they are the same Unix, you can't run SPARC binaries on Solaris/x86 or x86 binaries on Solaris/SPARC. Sun didn't even try. Separate CPUs, separate architectures. Sun's cross-CPU idea was Java, remember... and that is massively less elegant than NeXT's approach.
Every NeXT `.app` folder hierarchy contains native compiled binaries for every architecture the developer ticked the boxes for. As an experiment someone has made one with all supported architectures in it, I think I recall: a single `Myprog.app` bundle that contains 68030, PowerPC, SPARC, PA-RISC, x86-32, x86-64, and Arm64 binaries.
Because all the non-architecture-specific files are shared, meaning just 1 copy of every config file, script, image, icon, man page, help file, everything, Fat Binaries are only a double-digit percentage bigger for each additional CPU architecture you add. I forget exact numbers. Say 15% bigger say? So that 7-arch fat binary is only about 2x the size of a single-arch binary.
It is a _very_ clever and elegant hack, and on Linux, GNUstep faithfully implements the format and it works. So naturally, KDE ignored it, GNOME invented Flatpak, Ubuntu invented Snap, and there are half a dozen other more niche formats.
Because FOSS.
And none of them work on BSD. Any blasted BSD, doesn't matter.
Instead we have Cosmopolitan Libc and RedBean.
https://www.theregister.com/software/2022/06/20/unbelievable-a-single-file-web-server-that-runs-on-six-oses/1138195
If the FreeBSD foundation hired Justine Tunney away from Google, she could give them a cross-BSD binary format in weeks, one shared with Linux too. One binary for all the BSDs, Linux, and probably Android and macOS if she wanted.
The BSDs could all beaver away on their own kernels and filesystems and so on, and have all the additional packages, desktops and text editors and apps, in one shared package format and one shared set of repos. Jart's Cosmopolitan LibC makes that almost trivial.
https://github.com/jart/cosmopolitan
She calls them (and this triggers my meagre multi-alphabet reading ability horribly)
αcτµαlly pδrταblε εxεcµταblε
https://justine.lol/ape.html
But all the BSDs like to pretend that the others don't exist.
So it will never happen although it would help them all.
Anyway, no, I think tha trying to modernise A/UX would have been a bigger project than Copland itself, and sadly, NeXT was the best answer going.
Without Jobs and his Vision Thing (HT Andrew Eldritch & TSOM), with BeOS instead, I don't think Apple would have survived long enough to get a new BeOS-based MacOS out the door.
> And in an example of history repeating itself, ex-Apple people moved to Google where they couldn't get Fuchsia out the door in any meaningful way and Google decided to can it and merge Android and ChromeOS instead.
Now that is fascinating! I didn't know Gieselbrecht was involved in Android. He wrote the original NuKernel that is the basis of Haiku.
Of course Android uses Binder for IPC:
https://source.android.com/docs/core/architecture/ipc/binder-overview
And Binder came from BeOS.
https://events.static.linuxfound.org/images/stories/slides/abs2013_gargentas.pdf
-
Monday 28th September 2026 19:16 GMT Dan 55
Re: "SimpleText is unable to run because of a serious error"
NeXT only ran software for the architecture it was built for. There were three architectures (68K, PowerPC, and Intel) but there was no cross-architecture emulation. The .app bundles were just a way of putting several builds of the same program for different architectures into one bundle, if your architecture was missing from the bundle then the software didn't run, there was nothing like Rosetta. Also, classic Mac software was packaged differently so it wouldn't have helped. The kernel didn't do anything special with 68K code either, it was a kernel taken from a university project that could be compiled for different architectures.
Meanwhile A/UX used uses the AT&T V2 kernel with Apple modifications to make it more V3 like, there's nothing particularly special with A/UX's kernel either. It just needed a PowerPC build plus any extra work to port Apple's kernel modifications across to PowerPC.
Once that is done both Unixes are in the same position with a PowerPC build, although A/UX is a few years earlier than NeXT.
Now you need some way of emulating classic Mac software. The same PowerPC/68K emulator work that was started in Copland and ended up in MacOS would have worked on A/UX just as well, it boils down to running a classic Mac in a PowerPC/68K emulator on a PowerPC Unix.
Finally the GUI. NeXT needs time to develop the MacOS GUI from scratch. A/UX needs time to develop some way of using the classic Mac Toolbox as the Unix GUI. What at first glance seems interconnected isn't really such a great dependency after all - classic Mac software doesn't need to know anything about A/UX software and A/UX software just needs an API which does the same thing and returns the same result back to the caller. The classic Mac Toolbox could be emulated in another instance of the same emulator (faster to develop but slower software), be ported to A/UX (slower to develop but faster software), or maybe Apple could have started with the API in the emulator and gradually ported it across to A/UX in stages if they wanted to release something ASAP and then improve later versions.
Whatever barriers there were weren't insurmountable, any clever nanokernel was inside the emulator, not on the Unix side.
-
-
Tuesday 29th September 2026 15:40 GMT Charlie Clark
Re: "SimpleText is unable to run because of a serious error"
I think you're conflating Jobs' decision to focus exclusively on high-margin hardware and ending the clones with anything related to the OS.
As Dan says, Jobs brought impressive focus and determination to the business and was proven right in the end by focussing on turning brown boxes into desirable consumer electronic devices: he knew people didn't care about the technology but he'd learned that the hard way at NeXT. The comparison with the BeBoxen is flawed: those are best compared with Raspberry Pi's, which have their own geek port. The doomed from the start BeIA might be more reasonable but by then the cash needed for good industrial design was missing.
By 1998 BeOS had been ported from AT&T's Hobbit to PowerPCs to x86 with a skeleton team of developers, showing what was possible with a microkernel and a good API. This is still impressive today when you look at Microsoft's glacial process from x86 to x86_64 to ARM.
-
-
-
-
Monday 28th September 2026 09:10 GMT DrXym
Retrofitting pre-emptive multitasking wasn't easy
Trying to get a non-preemptive operating system running pre-emptively is a nightmare. All of the existing applications are designed to believe they're they only thing running in the foreground and the APIs and desktop are designed around that notion too, i.e. they're not reentrant.
Both Windows & MacOS sent preemptive applications to run a sandbox where their expectations about being the only thing running in the foreground could be guaranteed. Windows did it with a Win16 mutex (Win 95) or NTVDM (NT). OS X launched a MacOS 9 Classic session. Basically the applications were isolated while native software running through modern APIs (Win32 or Carbon) could run pre-emptively.
-
Wednesday 30th September 2026 22:50 GMT The Sprocket
And then there was 8.
I remember installing System 8 from a CD onto my PowerBook 520c. I had previously been using System 7 and the 'theme' extension Aaron. OS8 was the real deal, and it worked quite well. The System 8.1 smoothed off the rough edges. So many nice touches that are long gone in the MacOSs of today. Transfer processes had those long 'barber pole' progress bars that indicated something was happening. I remember those most when transferring HUGE 50mb+ Photoshop images to a Syquest disc. LOL! And what happened to the genie affect when you closed programs (apps) or chucked stuff to the Trash? Today there are no dodgy extensions to add. How boring.
Good times. Shortly after, at my instigation, our entire Marketing Department was running 8.1. Pretty smooth for the most part. The System 8 book I bought is still in my bookshelf.
