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!)
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.)
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.
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?
w10-1|3 years ago
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.
Taniwha|3 years ago
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!)
captainmuon|3 years ago
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).
KerrAvon|3 years ago
thewebcount|3 years ago
KerrAvon|3 years ago
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.)
astrange|3 years ago
The Unicode stuff did live on as ICU (https://icu.unicode.org) after being rewritten into Java and then back into C again.
randomifcpfan|3 years ago
Pink was doomed by inexperienced and optimistic technical leadership, partly caused by the original Pink/Blue split combined with the NeXT brain drain.
pjmlp|3 years ago
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).
pavlov|3 years ago
https://en.wikipedia.org/wiki/Star_Trek_project
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.
Maursault|3 years ago
"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.
AprilArcus|3 years ago
"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.
lukeh|3 years ago
pjmlp|3 years ago
> 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.
Taken from UNIX Adapter chapter
starmftronajoll|3 years ago
>Some day, the company might even want to run Pink on something really obscure, like an Intel processor ("bite your tongue!").
classichasclass|3 years ago
fizfaz|3 years ago
dingosity|3 years ago
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.
Eduard|3 years ago
https://en.m.wikipedia.org/wiki/Taligent#History
TIL Apple Pink is where Google Fuchsia gets its name from.
Reason077|3 years ago
It’s almost as bad as my AWS bill!
AlbertCory|3 years ago
You can rent it on AirBNB now.
[1] https://en.wikipedia.org/wiki/Big_Pink
cpeterso|3 years ago
exsf0859|3 years ago
Maursault|3 years ago
smcleod|3 years ago
jtbayly|3 years ago
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?
tomcam|3 years ago