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.
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!)
And yet there's still only one partial source code leak (for System 7.1) publicly available. Microsoft still has them beat on this. ;)
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).
Also feature parity between systems didn’t exist so they were still trying to one up each other.
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.)
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).
The Unicode stuff did live on as ICU (https://icu.unicode.org) after being rewritten into Java and then back into C again.
Pink was doomed by inexperienced and optimistic technical leadership, partly caused by the original Pink/Blue split combined with the NeXT brain drain.
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.
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).
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.
"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.
"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.
> 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
>Some day, the company might even want to run Pink on something really obscure, like an Intel processor ("bite your tongue!").
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.
https://en.m.wikipedia.org/wiki/Taligent#History
TIL Apple Pink is where Google Fuchsia gets its name from.
It’s almost as bad as my AWS bill!
You can rent it on AirBNB now.
