Hacker News Reader

Comment by jasoneckert | Hacker News Reader

As a longtime NeXTSTEP user, I still remember the first time I perused the filesystem of Mac OS X 10.0 (Cheetah) in 2001. And I distinctly remember thinking to myself that Apple basically took NeXTSTEP and slapped their own window manager and app framework on it only. The filesystem and toolset was nearly identical, and I even found several config files (I don't remember which ones) that still had NeXTSTEP listed in the comments.

As I evolved to develop iOS apps in the 2010s, NSObject (NS=NeXTSTEP) continued to be a reminder of this same lineage.

View on HN

> Apple basically took NeXTSTEP and slapped their own window manager and app framework on it only

Yup, that’s precisely it, and Apple made no secret of this. As early as the mid 90s, Apple knew their OS was a dead end and they needed to start over with a new OS as the base. Their in-house effort (Copland) was becoming an obvious failure and it was apparent they needed outside help. At the time a lot of people thought BeOS was going to be it, but the deal fell through when it became apparent that having Steve come back was a priority, and buying NeXT came with him. But it was always gonna be the case that the OS was going to be totally replaced and only surface level UI conventions would be maintained from classic macOS.

I wonder why exactly Copland went off the rails, do we have anyone from the Copland team here on HN who can share their view?

I’d love to know more about its design too

Apple published a book about it: https://dl.acm.org/doi/10.5555/524838

A bunch of documentation was posted here, although I’m not sure the links still work (might need to go through archive.org)

https://www.pagetable.com/?p=211

From the wikipedia page it was that they were just adding feature after feature. As an aside it is very interesting that Classic Mac OS was attempted to be replaced by a microkernel twice but was successful because they figured out how to ship NeXT with fresh paint and an slightly improved window manager that really was just NeXT if you compare the two. (A/UX https://en.wikipedia.org/wiki/A/UX, Copland https://en.wikipedia.org/wiki/Copland_(operating_system)

I think “slightly improved” and “fresh paint” undersells the work Apple did. Replacing the NeXTstep Display PostScript server wasn’t a small thing!

With PDF? Afaik it's a subset of PS so their main work would be in reducing the amount of PS features.

Mike Paquette wrote extensively about the effort involved to replace Display PostScript (which NeXT mostly wrote) with "Display PDF" as Quartz is often referred to as.

See postings to usenet on comp.sys.next.*

I'd love a link or two if you can dig them up.

It would have been in a thread like to:

https://groups.google.com/g/comp.sys.mac.advocacy/c/OLc8T6KO...

As I noted in another comment, it was a remarkable accomplishment that Mac OS X was reasonably recognizable to Mac users and ran the same apps (via Classic and Carbon), all while having a completely different core OS under the hood (though as another poster noted they had prior experience building Mac-on-Unix environments.)

Apple has pulled off a number of surprisingly successful "brain transplant" transitions for the Mac platform, including moving from 68K to PowerPC to intel to ARM. In each case, the user experience remained largely the same and old apps continued to run via emulation.

This was the second go at it, they already tried once with A/UX, even though it wasn't as well integrated, nonetheless there was this previous experience.

You missed MkLinux, but of the three (Copland, A/UX, and MkLinux), only one of those was ever slated to be the future of the Macintosh. A/UX was very interesting, but it was also encumbered with a fairly expensive UNIX license and was never really a consideration as a replacement for the existing Macintosh System software. Neither was MkLinux.

Yes. Focus is about saying “no.” None of the Copland management or marketing people ever said “no”. So instead of just porting the Mac toolbox to C and a microkernel and shipping that as a first step, it had to have a new filesystem API (so abstract that it will support non-hierarchical filesystems!), and a new OO system for handling text strings, and a new UI toolkit, a new help system, oh, and an OpenDoc-based Finder… A lot of potentially good ideas, but you simply cannot do that all at once.

It wasn’t actually a completely lost cause. They could have shipped it in six months if they’d just simplified the damn thing to a native UI toolbox on top of a microkernel, API additions cut to the bone. (One of the problems with that plan, though, is that product marketing wants all the features you can cram in, so you have to be willing to tell them “no” too.)

Anyway, Gil Amelio and Ellen Hancock also didn’t know how to manage software projects, so instead of fixing what they had, they decided to buy outside tech. Which means we got the iPod, the iPhone, etc. But, in context, they were total dumbfucks; they could have gotten there with what they had.

That is a bold claim. If they do not know … how can they do that. And a technical solution to exist need management know-how, financial viability or at least the market allow you to play out.

That is why even if you were right, within Steve Jobs there would not Apple.

World need to have a mix or proper mix of important things. The reason why communism fall always not because it’s ideal but because it is wrong in human level. You need a mix. A proper mix.

Gil took over as CEO two years after the Copeland project began under Michael Spindler, and turned it around enough to ship Mac OS 8 a few weeks after he was ousted by the board (after Jobs broke a gentleman's agreement he had with Amelio and sold his 1.5M shares, tanking the share price).

Gil Amelio was not a great CEO by any measure, but he deserves credit for helping save Apple. He uttered the first "no". "No", we are not going to ship this Copeland thing, it's hopeless, we either have to buy another OS and build from that, or sell the company because we're out of time.

One reason was that they tried to have both a preemptive OS with memory protection and backwards compatibility with existing OS extensions, which frequently patched OS calls left and right, read and wrote memory across process boundaries, etc.

For example, there was no support for screensavers in MacOS classic; screen savers such as After Dark hacked that in by patching various OS calls. There was no support for Adobe type 3 fonts; Adobe Type Manger hacked that in. There was no support for showing a row of extension icons on-screen as they loaded; an informal protocol was created by various extension-writers to support that.

It's incredible that it only crashed once a day!

Even Mac OS X early on had problems.

I actually maintained a "Crash Log" at the entrance to my cubicle, recording how many times a given application had crashed that day/week/month/year and ultimately extended it to record even the preceding years.

Quark XPress 6 required a colour-coding which reached into the hundreds for a given year (my recovery folder got cleared out once a week and had hundreds of GBs of files in it most Fridays), and Adobe Acrobat wasn't far behind (but no recover folder), while the OS itself was quite reliable --- work done using TeXshop and other Cocoa apps rarely crashed or had problems.

It was a big change from NeXTstep, where I can only recall one software crash, and two hardware faults (SCSI) during college, which was the high-water mark of my GUI experience, w/ a NeXT Cube (w/ Wacom ArtZ and a scanner) and NCR-3125 (running Go Corp.'s PenPoint) and Apple Newton MessagePad all connected together using a serial interface to write papers and take notes and do graphic design work on.

I know there was more to it than that, but it seems to me that a better managed Apple in some alternate history might have just thrown all the extensions "support" out, shipped, and said there would a better documented API for that kind of crap in the future. Probably also not waste time on OpenDoc because there was no shot that was ever going anywhere if you considered it from Microsoft's, QuarkXpress's and Adobe's perspectives.

Which is basically one of the reasons Mac OS X actually ended up shipping. You got a Classic VM in an OS that otherwise didn't care about making breaking changes, but you had a sliding scale from Classic to Carbon to Cocoa to fix your software eventually. Also OpenDoc got thrown out of consideration very early in the house cleaning process at Apple.

The BeOS guy asked too much from what I recall. I think the BeOS thing fell through before Mr Jobs quietly returned in 1997.

As I recall, BeOS was asking on the order of $80 million, NeXT was acquired for $400 million.

I found this reference, so 80 valuation, Be wanted upwards of 200, “In 1996, Apple Computer decided to abandon Copland, the project to rewrite and modernize the Macintosh operating system. BeOS had many of the features Apple sought, and around Christmas time they offered to buy Be for $120 million, later raising their bid to $200 million. However, despite estimates of Be's total worth at approximately $80 million,[citation needed] Gassée held out for $275 million, and Apple balked. In a surprise move, Apple went on to purchase NeXT, the company their former co-founder Steve Jobs had earlier left Apple to found, for $429 million, with the high price justified by Apple getting Jobs and his NeXT engineers in tow. NeXTSTEP was used as the basis for their new operating system, Mac OS X.”

https://en.m.wikipedia.org/wiki/Jean-Louis_Gass%C3%A9e

“BeOS did not have printing” was the insult thrown around at the time.

I don’t remember the exact number, but BeOS was too incomplete at the time to spend what they were asking, and maybe to purchase at all. There was no way to print documents, which still mattered a lot for a desktop OS in 1996. It needed a lot of work.

Now, in retrospect, Apple had time; Mac OS X wasn’t ready for the mainstream until 2003-2004.

To be fair, printing in 1995-6 was a huge can of worms and hell on earth.

ISTR those of us using HP or Apple printers were generally in pretty good shape at the time. Can’t vouch for other brands.

Apple didn't support anything other than PostScript natively at the time, so their printers came with postscript support. HP made special models for use with Macs that shipped with PostScript included.

Apple sold a ton of printers without PostScript:

https://en.wikipedia.org/wiki/List_of_Apple_printers

The earliest ones pre-dated PostScript by years.

Send PostScript, done. Today it's figured out what driver will properly rasterize exotic things like ligatures because we decided that throwing a real CPU in the printer was a mistake.

96 was still a few years before all the printers natively supported postscript - HPs had their own vector graphics library for example.

Many printers in common use were still “one font wonders” and that resulted in lots of fun.

Unless you were using anything from that tiny obscure Hewlett Packard operation and didn’t want to shell out for a module. HP never promoted Postscript. It was far from universal as an embedded PDL.

> that throwing a real CPU in the printer was a mistake.

The CPU in any decently modern printer is still many times more powerful than what was in an original LaserWriter (30ppm and up needs power, even if it’s simple transforms and not running wankery). It’s not just about CPU power and modern laser printers still support PDL and vector languages like PCL and PDF (and many have some half assed often buggy PS “compatibility” eg BRScript), the bigger mistake is using general purpose Turing tarpit that is “powerful” rather than a true high level built for purpose PDL. PostScript just isn’t very good and was always a hack.

> Send PostScript, done.

The other problem of course being that raw PostScript as a target for most applications is not at all elegant and ironically too low level. So even if you wanted postscript, an OS that didn’t provide something more useful to most applications was missing core functionality. The jwz quote about regexes applies just as well.

I have a modern Canon laser printer that does not properly implement ligatures because of obscure driver issues. What I see on the screen is not what is printed.

Text layout is hard and unfortunately drivers and firmware are often buggy (and as printing is lower and lower margin that doesn’t get better). But just throwing a weird language engine in doesn’t actually solve any of those problems.

Text layout doesn't need to be done when the source is a PDF. Make printers do the PDF and let Adobe control trademark access via conformity tests and life is good.

> Text layout doesn't need to be done when the source is a PDF.

PDF isn’t entirely a panacea, since it’s complex enough that printing any random PDF isn’t trivial at all, but sure, close enough, but before you were talking about Postscript.

> Make printers do the PDF and let Adobe control trademark access via conformity tests and life is good.

PDF printers aren’t all that uncommon. So why doesn’t your Canon do this? These aren’t technical issues at all. This is an economic/financial problem as mentioned (doing business with Adobe!). This isn’t about part cost, a CPU 100x more powerful than the one in the LaserWriter is nothing.

The biggest errors I’ve found are when the PDF says it’s using FontX or whatever, the printer claims to support the same version, and it’s subtly different.

The PDF tool assumes it doesn’t have to send the full font, and the document garbles. Print as image sometimes gets around this.

There was a time when the fastest 68k processor Apple shipped was in the LaserWriter (12MHz instead of 8Mhz in the Mac).

I seem to recall a story of someone internal to Apple figuring out how to run a compiler or other batch processing system on the LaserWriter as a faster quasi-coprocessor attached to a Mac.

Oh I knew that was coming. This interesting but ancient piece of trivia just illustrates something about how slow micros were back then. It’s not like printer don’t have more and multiple CPUs today. Not like whatever poorly written outsourced to India “managed” shit and other features are going to run on a potato. Whatever is driving the color touch LCD on even the Walmart econoshit is many times more powerful then that 12 MHz 68k.

Still have no idea what the GPs point was. You can just as easily run a raster on the host, if it has bugs it has bugs, where it lives doesn’t matter.

Further rosetinting is of course that LaserWriter was $20k and it’d be a decade plus before a monochrome dropped under 1. I’m gonna guess the Canon with the shitty drivers is 10x cheaper and faster.

The amount of data transfer for 300x300 DPI full page images is high even now, most printers still render fonts and such internally.

It really isn't that much though. A 1200x1200 DPI monochrome image on Letter size (not even considering margins) paper is on the order of 16 MiB uncompressed. And bitmaps of text and line art compress down heavily (and you can use a bitmap atlas or prerendered bitmap font technique as well). It’s also usually easier to upgrade RAM in a printer than a crappy firmware.

> most printers still render fonts and such internally.

Many printers have some scalable font rendering capability, but it is often not usable in practice for high fidelity. You absolutely can raster on the host to either a bitmap font, or make use of the PDL's native compression. Most lower end printers (which is pretty much the bulk of what is sold) do not have the capability to render arbitrary TrueType fonts, for instance. A consumer/SOHO level Canon laser using UFRII is going to rely on the host for rastering arbitrary fonts.

Don Lancaster (outside of Apple) did that. In fact, he ignored the Mac and connected a LaserWriter directly to his Apple II, and programmed in straight PostScript. Used that language the rest of his life. All the PDFs on his site were hand-crafted.

I remember that time. I was taking a graduate level intro to graphics class and we had an assignment to write a ray-tracer and turn in a printout of the final image along with a printout of the source code. The instructor allowed any programming language, so I used a different one for each assignment.

For the ray tracing assignment I used postscript, the PS image operator calls a function to return each sample in the image. The transform matrix made scaling the image easy.

My code was two pages long, up from one page because of the many comments. I think the next shortest was 15 pages. It also ran faster than most others because of the faster processor.

> Unless you were using anything from that tiny obscure Hewlett Packard operation and didn’t want to shell out for a module. HP never promoted Postscript. It was far from universal as an embedded PDL.

it's why HP had a series of printers marketed explicitly for Macintosh use, whose difference from the otherwise same model was that PostScript interpreter module was included as standard, as Mac didn't really support non-postscript printers with anything resembling usability

The high price was also justified by the success of WebObjects at the time, which was seen as a potential fuel for an IPO for NeXT, even though WebObjects was not what Apple was buying it for. This Computer History Museum article goes into that angle in detail: https://computerhistory.org/blog/next-steve-jobs-dot-com-ipo...

I think Steve ended up being a better salesperson than Jean-Louis Gassé. And to be fair, for all its incredible effort I don't think that BeOS was as mature as NextStep.

As I recall, there were some early UI efforts that essentially copied the Classic MacOS feel (the MacOS 8/Copland look) onto NextStep, but they were dropped in favor of OS X's Aqua design (which took inspiration from the iMac design)

Mac OS X Server (Rhapsody) was using the classic Mac OS look over a NextStep base. You can find x86 versions online which work in VM, for nostalgia and research.

To be a bit more specific, Mac OS X Rhapsody DR2 (1998) was the last x86 Mac OS build to ship until the x86 Developer Transition Kit shipped with Mac OS X Tiger 10.4.1 in 2005, and Rhapsody DR1 was the first, and only other, pre-Tiger x86 Mac OS release, though unreleased x86 ports of earlier, pre-NEXTSTEP Mac OS releases were demonstrated internally[1].

Additionally, NeXT shipped several x86 releases of NEXTSTEP and its successor OpenStep (NEXTSTEP 3.1–3.3, 1993–1995; OpenStep 4.0–4.2, 1996–1997) prior to the acquisition, all of which also run under virtualization with some effort — though I'd personally recommend the Previous emulator[2] for running older NEXTSTEP builds, as it runs reasonably fast on modern hardware and quite a bit of historically interesting NEXTSTEP software exists that was never released for versions of NEXTSTEP running on non-NeXT hardware (Mathematica 1.0, Lotus Improv, WordPerfect, and the original CERN WorldWideWeb browser come to mind, though source ports of the latter exist).

[1] https://en.wikipedia.org/wiki/Star_Trek_project

[2] https://www.nextcomputers.org/forums/index.php?topic=2642.17...

Do command line programs built on Rhapsody DR2 (x86) run on Tiger (x86) or vice versa?

>I don't think that BeOS was as mature as NextStep

BeOS was interesting but also kind of a joke. I remember trying it out and receiving error messages written as not-helpful haikus. I could only think that this was not a serious OS, and that was the end of BeOS for me. Here's a few:

"Errors have occurred. We won't tell you where or why. Lazy programmers."

"The code was willing. It considered your request, But the chips were weak."

"Cables have been cut. Southwest of Northeast somewhere. We are not amused."

As a programmer at the time, I was confounded by these awful error messages. It just made the whole thing seem like a joke. I had no time for this. I'd never consider writing software for a platform that obscured the error behind a haiku.

Is it really better to print “Unhandled exception” or “Internal server error”?

Sometimes there just isn’t more context available to an error. This was even more the case 30 years ago, when errors were often nothing more than a numeric code — and then you look it up and it’s just some “unspecified data error.”

BeOS tried to make light of that quandary.

Just because the computer doesn't know why it crashed doesn't mean a human won't. At least print out a stack trace, or something, then print the haiku. Give someone a chance at figuring out what went wrong. Maybe there was a developer mode I wasn't aware of, but at least Windows at the time (3.1 and 95) was capable of giving the user some indication about what part of the software crashed, whether or not the user knew what to do with it. My first impression of the OS is what led me to avoid it, it's that simple. I don't know why other people didn't adopt it, I can't speak for them.

I think that probably is the case that the moment the computer throws an error, potentially having lost some work-in-progress data or any other "funny" consequence like that, is the moment the user is less likely to be receptive to jokes.

Actually didn't know that about BeOS, and suddenly the name of the Haiku Project makes a lot more sense to me.

I thought those haiku error messages were only in NetPositive (the BeOS web browser).

But holy shit were those BeBoxes sexy as hell. As a teenager, seeing them for the first time, in an era of soulless, beige, badly named Macs like the "Performa", made a lasting impression that I still remember 30 years later.

Those twin vertically arranged CPU usage LEDs running up the sides of the case, pulsing as the box churned through multiple windows of buttery smooth video playback, while the operator simultaneously read and wrote to the disk, accessed the network, and manipulated the filesystem–without ever stuttering, dropping frames, or beachballing–was really quite something at that time. BeOS could multitask in a way nobody else was doing, and macOS still cannot match it.

Still think it would have been interesting to not let some of that tech die on the vine.

https://www.haiku-os.org/

and they had a "geek port" -- what nerd wouldn't love a machine with a GEEK port?

It was a GPIO port you could wire stuff into, think it even had ADC's and DAC's for analog signals. The case mounted LED CPU meter bars were sick - like an 80's amplifier VU meter. Amazing bit of kit those machines - true hacker boxen.

It wasn't really. It was just another closed platform. BeBox had a real struggle to boot anything but BeOS and the platform was so poorly documented that other than the manuals that came with it and the few brief descriptions in Be Newsletters, there is no real public documentation about any of the hardware. It was also smoke and mirrors, it barely worked in MP mode because the 603's they used didn't do proper MP. There was a software process that had to work around this, which then slowed down the OS in general. The dual processor Mac's with 604's actually ran rings around the BeBox performance wise.

At the time apple looked at beos, the print subsystem was... far from complete. There were probably many deal killers with Be, but this was the one I remember people kept repeating.

> I don't think that BeOS was as mature as NextStep.

It certainly was not. It was single user only - no way to log in with different users, no accounts, just a single default user.

Networking performance was awful in R3 and R4. In R5 they replaced the user space network stack with BONE, an in-kernel IP stack that promised better performance. By then, too late as the Palm sale was around the corner. I remember talking to JBQ (Jean-Baptiste Queru) on IRC about this and how that effected their micro-kernel design and JBQ stated that their claim of micro-kernel was for marketing purposes only.

It was a multimedia first system designed by multimedia geeks. Fun for its time and had a lot of great ideas.

Nitpick: BONE was part of R5.1 "Dano", which got leaked but never publicly released.

Nitpick, nitpick: BONE was actually a BETA for R5 also, but it was also never released. The Dano version was much more mature and Dano in general is a much later version of BeOS with a lot of changes under the hood.

They even “buried” MacOS 9 in a WWDC keynote.

Steve Jobs coming back was not really a deciding factor. In retrospect Steve Jobs was essential to Apple’s success after taking over, but when the acquisition happened, there was little reason to expect that. The conventional wisdom at the time was that Steve Jobs did a good job founding Apple and running the Macintosh project, but he wasn’t fit to run a company the size as Apple. NeXT, if anything, vindicated that impression with a string of high profile product flops. At the time of the acquisition, Apple was dying, and NeXT had spent over a decade and billions of dollars growing into a company that could, at best, hope to be acquired by a dying Apple.

The choice of NeXT over Be mostly came down to NeXTStep being a genuinely better operating system than BeOS in many ways as well as Gassee overestimating his own negotiating position. Steve Jobs managed to take over the company, but this was clearly not the intended outcome because almost all of the executives who were involved in the decision to acquire NeXT were fired in the process, and after Jobs took over he also forced almost the entire board to resign as well.

Jobs also (in)famously sold all of the APPL stock that he received in the NeXT acquisition, saying that he had no faith in Apple leadership at the time.

In retrospect, this sale cost Jobs a ton of money. Of course he ended up doing fine, mostly because of the Pixar acquisition by Disney.

Yes, this was one of the moves in his coup against Amelio, and part of what led to Amelio being fired by the board, at which point Steve Jobs took over on an "interim" basis and promised to search for a new permanent CEO.

Not quite. He sold his shares in 1985. I think technically it was all except one so he could still get investor reports, but that last part might be apocryphal.

https://www.cultofmac.com/news/today-in-apple-history-steve-...

You're looking at the wrong year. From 1997: https://www.sfgate.com/business/article/steve-jobs-confirms-...

Oh, you know what? Good point. I forgot that the NeXT sale included a transfer of stock and wasn’t even thinking about it. I stand corrected!

> their own window manager and app framework on it only

Window manager in this case including Quartz/Core Graphics (replacing Display Postscript) as well as complete UI facelift/transplant that turned the NeXTSTEP file browser into the Mac OS X Finder (even if it imperfectly copied the spatial orientation of the classic Finder.)

App framework being not only a Mac flavor of AppKit/Foundation/NS* (Cocoa) but also a virtual legacy Mac OS layer (Classic) as well as a hybrid API (Carbon) that worked on Mac OS 9 and OS X, providing a fairly complete Mac app transition strategy (classic -> carbon -> cocoa).

Cocoa also worked with the (later abandoned) Java bridge as well as Objective-C++ and OSA/AppleScript/etc.

NS stood for NeXT and Sun. NX was the original prefix before OpenSTEP.

EDIT: I might be wrong about the first part, see my comment below.

Uh, that‘s interesting! Do you have a source for this (or is it firsthand knowledge?)

I have an original "NeXTstep Concepts" manual with the NX prefix. I can't remember where I heard the "NeXT and Sun" explanation for the first time, but a Google search shows that the prefix change could've actually occurred before the collaboration with Sun. It could stand for NeXT Software, as it's closer to the transition to a software company.

The "NS" prefix was introduced with OpenStep in 1994[1]. OpenStep was a collaboration between NeXT and Sun[2]. So the S in "NS" referring to Sun is certainly plausible!

[1] https://developer.apple.com/library/archive/documentation/Co...

[2] https://en.wikipedia.org/wiki/OpenStep

Per bbum and others, NS long predated Sun getting involved.

A person that was involved with the project claims the prefix predates Sun's involvement [1].

> Totally wrong. The NS prefix predated Sun signing on to implement the OpenStep spec by quite a bit. It was either NS for “NeXTStep” or “New System”. None of us can remember which, though, but definitely not NeXT-Sun.

[1]: https://x.com/bbum/status/1260304075305791488

I first read that in a Fabien Sanglard book, probably Game Engine Black Book: DOOM?

According to Wikipedia, NS stood for NeXTSTEP: https://en.wikipedia.org/wiki/Foundation_Kit#:~:text=This%20....

I do remember people in my circles thinking it stood for NeXT Software (which was likely a more suitable name for its use at the time).

This is what I’ve heard. If true it’s funny as it effectively eliminates Sun’s inclusion in the acronym because everyone assumes it’s NextStep.

Nope. NeXT switching from NX to NS predates Sun's involvement.

Reply on news.ycombinator.com