Pink did get rolled into Taligent, the Apple/IBM JV to overcome Windows NT.
Remember that mac 68K system calls were via ("A-line") opcodes, and their only extension/fix mechanism was head- and tail-patching those entry points. 1990 was only about 2 years after quickdraw was re-written in C instead of assembler. Also, application developers made assumptions, e.g. sending F-line opcodes thinking any 68020 machine has an FPU (sorry!). So OO looked like the way out from that tangle.
Leaking tech docs were a big problem as Apple sought buy-in from partners. The "56" watermark might have overtly supported traceability back to the recipient. In ~1993 at Taligent we would also covertly vary variable names and such in sample code we delivered to different partners, after we found the code being shared anonymously.
Due to the OO scaffolding, the simplest application required implementing ~35 classes (yuck!), but the promise of modular intermixed code/edit/data (opendoc) was largely realized (yay!) before HTML and MIME types made complex data/display trivial (oh well).
As the length of the document shows, both Taligent and Copland were ... bedeviled with a million mid-level tyrants producing huge volumes of technical blabbage. Tremendous waste of brains, while a few sharp people were poking around Mach and finessing hardware abstraction layers.
Hoops (dev-env) and i18n seemed to be the only things that came out of that, and IBM pushed i18n into Java.
Yeah my impression of Apple at the time was that they leaked like a sieve - yet at the same time Steve was a petty tyrant who would jump on anyone who was caught.
I worked on A/UX at UniSoft, we got half of the first dev run of MacII boards (I got to find hardware bugs), I stopped attending BMUG and we chose our own internal code name (Pigs in Space), when the project finally leaked it was as "Eagle" Apple's code name (whew!)
Steve was long gone by the time Pink existed. Apple leaked (mostly from the top!) until Steve became CEO in 1997, and he clamped down on leaks pretty hard.
Yeah but he was around while we were working on A/UX, I remember visiting Apple and people hiding from him (or rather keeping their heads and voices down in a cube farm when he passed by "shhh Steve's coming")
Steve Jobs resigned from Apple in 1985 and returned in 1997. Steve Wozniak also left about around the same time, sold most of his Apple stock, and founded CL 9 in 1985. I'm not sure when Apple contracted Unisoft initially, but A/UX wasn't announced until early 1988, and there was at least a year of development underway already.
Apparently Jobs sold most of his interest in Apple immediately in 1985 in order to finance founding NeXT the same year. Jobs took a number of Apple employees with him to NeXT, but I'm not sure how long he was speculating who he wanted with him. Yada yada yada, Apple and NeXT were in negotiations by 1996. I have heard that A/UX was the first thing Jobs killed when he returned in 1997, but the final release of A/UX was version 3.1.1 in 1995, and Apple abandoned it a year later.
So if it was Steve Jobs they were hiding from, it would have either been very early in the development of A/UX (if that occurred by January 1985) or Jobs somehow started killing A/UX during early NeXT negotiations with Apple in 1996. Or Jobs had some reason to be at Apple during that period due to Pixar(?)
And if it wasn't Steve Jobs, then there was another Steve at Apple that was menacing employees between 1985 and 1996. Steve is a relatively common name, and it would be pretty interesting to learn who that was.
I am a fan of A/UX, though I didn't appreciate being forced to buy a license for it in 1989 by my university's CS department. Though the price dropped by about half by then, along with the MacII hardware, it was a very expensive purchase for a 17yo, about as much as a midrange car at the time.
Why was leaking tech docs considered such a problem? I could imagine any competitor large enough to copy implementation from docs and unscrupulous enough to do so would be able to get their hands on all your docs anyway (say, a Microsoft exec hiring a PI, ...). But what's the harm if anybody else gets their hands on the docs? Is it some abstract legal "we must not accidentially make any forward-looking statements", or is it just not wanting to make anything public just in case?
If anything, I would think you'd want to have technical documentation circulated as widely as possible, so application developers don't have to reverse engineer your interfaces (which would take longer and be more error prone).
I don’t think the length of the document indicates anything in itself. This is an entire operating system written from scratch. There should a lot of design documentation.
Reading through the first few pages, I’m impressed with their bluntness about the shortcomings of the original MacOS. While Pink itself failed, they actually managed to achieve a lot of the stuff they discuss in that document, even before the switch to OS X. I remember when they started moving low-memory globals into system calls. And, obviously, they did eventually get it working with other processors. This makes me think 2 things: 1) You can achieve something if you have a plan, and 2) What you plan won’t be what happens, but you may still achieve the same goals a different way.
I mean, the problems were known in 1985-1986; a real indictment of Apple’s executive management during this era that once they finally had a solution underway, they threw it away only to start over again with Copland years later.
I mean, it wasn’t until 2003 before Apple was able to shipp an OS remotely embodying anything here for most end users. (Pre-Jaguar Mac OS X was not ready to install on grandma’s iMac.)
> it wasn’t until 2003 before Apple was able to shipp an OS remotely embodying anything here for most end users
Perhaps I wasn't most end users, but I was able to leverage a Mac 8500 from 1997 with an upgraded dual G4 450MHz daughter card to run Connectix Virtual PC and Windows XP on 10.0 Cheetah in 2002 (daughter card would not support newer OS versions) in order to attend remote online A/V Blackboard courses for a semester at my alma mater. The virtualization was a lame dog, but somehow it worked well enough for me to complete the courses, and I can only assume the base Cheetah operating system performed far better on contemporary Mac hardware (which would have been the 2002 Quicksilver, G4 800MHz up to dual G4 1GHz).
Pink eventually collapsed under the weight of bad choices like "using C++" and "inheritance-based OOP". You can more or less tell it was going to fail from this design document; it is just way too long and seems to have like 5 years of work pre-planned.
The Unicode stuff did live on as ICU (https://icu.unicode.org) after being rewritten into Java and then back into C again.
I don’t think C++ and inheritance based OOP inherently doomed Pink. BeOS was also C++/OOP, and NextStep/macOS’s use of ObjectiveC/OOP is very similar to C++/OOP, since pre-ARC Objective C is similar to C++ with a slightly more dynamic way of making late-bound function calls.
Pink was doomed by inexperienced and optimistic technical leadership, partly caused by the original Pink/Blue split combined with the NeXT brain drain.
> "I don’t think C++ and inheritance based OOP inherently doomed Pink. BeOS was also C++/OOP, and NextStep/macOS’s use of ObjectiveC/OOP is very similar to C++/OOP"
The use of C++ with inheritance based OOP was a huge technical limitation for BeOS at the time, because C++'s virtual method tables resulted in very brittle ABIs. Just about any changes to the virtual method definitions in a base class (even as simple as adding a new method!) could break code compiled against the old version. BeOS had all sorts of "placeholder for future function" nonsense in their headers to try to work around this, but it was very ugly.
This wasn't an insurmountable problem, because eventually it could have been solved with some sort of C++ aware dynamic linker. But at the very least it would mean an ugly ABI-breaking change at some point requiring all apps to be recompiled.
Objective C was quite different from the start because it's "message send" mechanism shifted virtual call resolution to runtime, making the whole programming environment more dynamic. Crucially, as long as function names don't change, old compiled apps can basically keep working forever.
Objective-C still had the "fragile base class" problem because its classes' ivar offsets were known across library boundaries, so they couldn't be changed, but C++ had (and still has) this for code with vtables as well. It was finally fixed with the x86-64 ABI.
Taligent had their own compiler and used something similar to what the ObjC 2 ABI uses for ivars for all member variables and functions to eliminate the fragile base class problem. “Using C++” may have been part of their problem, but not for the same reasons as it was for BeOS.
In addition to siblings comment COM and OLE are pretty much alive to this day on Windows, being the main way of accessing the platform since Longhorn ideas were ported from .NET into COM in Vista.
WinRT for all its flaws, is basically COM with an additional base interface (IInspectable), .NET type system metadata instead of TLB, and application identify.
Then Android has similar ideas via Android IPC (and Binder).
It worked, but all the apps needed to be recompiled for x86, and it didn’t tick any of the advanced feature boxes like Pink/Taligent did. (Which notably ticked all the boxes and never shipped.)
Still I think MacOS on x86 could have been a contender against Windows 3.1. Had Microsoft refused to port Mac Office to x86 or tried to pull their licensing shenanigans against Apple, it might have made a stronger and earlier antitrust case at least.
> Still I think MacOS on x86 could have been a contender against Windows 3.1.
"MacOS" is slightly ambiguous because of the nomenclature changes, though Star Trek was System 7. The nomenclature (ignoring iDevice os names) evolves from System 1-7, Mac OS 7.6 - 9.2 (aka "Classic"), Mac OS X, OS X, and finally macOS, but all these names really only represents two distinct operating systems across 4 distinct hardware platforms.
The Star Trek project also initiated in 1992, after the PowerPC AIM alliance was formed. PowerPC was promising and apparently pretty exciting, with RISC able to do more with less processor cycles than x86 CISC. But by the late 1990's and early 2000's, Motorola had sold its PPC division to Freescale, and IBM had sold off its embedded chip applications and spread out into game console processors. Apple (Jobs) wasn't happy with IBM's delays in advancement or the roadmap, and by 2005 Apple announced the platform switch to x86.
Oh, this is incredible! I've always wished I could have been a fly on the wall during this boondoggle.
"Jaguar", mentioned early in this document, was a RISC platform based on the Motorola 88000, which was abandoned in favor of and/or rolled in to the PowerPC project that shipped in 1994, four years after the date on this document.
Love that the UNIX compatibility layer is called Don Quixote, and how the document reveals the way UNIX was always seen from Apple glasses.
> Don Quixote is not intended to be a replacement for a standard full-featured UNIX system -- rather, it is a reduced-complexity UNIX for "the rest of us" who want some or all of the capabilities of UNIX but don't want the difficulties associated with a standard UNIX.
> ...
> Both NeXT and A/UX are using this approach to attempt to turn a relatively traditional UNIX workstation into a personal computer. The "wrapper" approach does not address the fundamental problem -- the complexity of UNIX.
Yup. This is an interesting time for the project. It's after the '88 meeting where they separated features onto blue (easier), pink (harder) and red (hardest) cards and before '91 when they were actively talking to IBM about what would eventually become Talingent in '92.
They've had enough time to think about things and get some early coding experiments under their collective belts, but not so long that the impact of infighting (and mild panic) is so apparent.
I contributed a small bit to a serial port manager in this time frame. In retrospect, it's clear they wanted something that could work on different hardware (like the 16550 popular in PCs and Z8530s already used by the macs) - but I'm a little sad to see it isn't mentioned here.
Pink, Valhalla, Thor, Pluto, Babel, Rainbow Warrior, RedEye … these guys sure must have spent a lot of time coming up with catchy code names for each and every subsystem.
Why would you be willing to download a PDF via HTTPS but not HTTP? If PDF's can be dangerous, then they can be dangerous regardless of which server they are downloaded from. Am I missing something?
Remember that mac 68K system calls were via ("A-line") opcodes, and their only extension/fix mechanism was head- and tail-patching those entry points. 1990 was only about 2 years after quickdraw was re-written in C instead of assembler. Also, application developers made assumptions, e.g. sending F-line opcodes thinking any 68020 machine has an FPU (sorry!). So OO looked like the way out from that tangle.
Leaking tech docs were a big problem as Apple sought buy-in from partners. The "56" watermark might have overtly supported traceability back to the recipient. In ~1993 at Taligent we would also covertly vary variable names and such in sample code we delivered to different partners, after we found the code being shared anonymously.
Due to the OO scaffolding, the simplest application required implementing ~35 classes (yuck!), but the promise of modular intermixed code/edit/data (opendoc) was largely realized (yay!) before HTML and MIME types made complex data/display trivial (oh well).
As the length of the document shows, both Taligent and Copland were ... bedeviled with a million mid-level tyrants producing huge volumes of technical blabbage. Tremendous waste of brains, while a few sharp people were poking around Mach and finessing hardware abstraction layers.
Hoops (dev-env) and i18n seemed to be the only things that came out of that, and IBM pushed i18n into Java.