Live data from Hacker News

Apple Big Pink #3 (1990) [pdf]

bitsavers.informatik.uni-stuttgart.de

21–30 of 40 posts

Re: Apple Big Pink #3 (1990) [pdf]

#21
Around this time there was also Apple project “Star Trek” which ported System 7 to x86:

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.

Re: Apple Big Pink #3 (1990) [pdf]

#24
post #23
post #22

Earlier quoted context omitted.

Some of us live on the edge

Does edge not support HTTPS yet? (I'll walk myself out....)

Get it from a different Bitsavers mirror [1] if you are that fussy.

[1] https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ap...

Re: Apple Big Pink #3 (1990) [pdf]

#27

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…

> "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.

Re: Apple Big Pink #3 (1990) [pdf]

#28

Earlier quoted context omitted.

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…

> "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…

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.

Re: Apple Big Pink #3 (1990) [pdf]

#29
post #8

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 a…

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).

Re: Apple Big Pink #3 (1990) [pdf]

#30
post #17

A PDF file from a server without HTTPS seems a little dodgy?

Help me out.

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?

Post reply on HN