Comment by ndiddy | Hacker News Reader

Comment by ndiddy | Hacker News Reader

Parent Full thread

Some former Be employees have commented here in the past saying that Apple made the right decision to buy Next and not Be from a technical perspective, as BeOS had poor code quality and was far behind NEXTSTEP in important areas like networking and printing. They also implemented the OS API directly in C++, which tied them to a specific C++ compiler (some mid-90s version of GCC) due to the ABI getting broken in newer versions. The 32-bit version of Haiku (modern BeOS reimplementation) supports BeOS software, and as a result still needs to be compiled with that mid-90s GCC release.

Beyond that, I'm not sure if buying Be would have fixed the managerial problems at Apple. Would they have been able to add the required features to BeOS to turn it into a production OS without the project turning into another Copland? Would the existing Apple management have slimmed down the massive Apple product line that had dozens of nearly identical models? Would it have gotten rid of dead-end projects like Newton and Pippin? Etc.

Former Be person here. Excellent summary. To further elucidate the management issue, some of the Be management went to Palm and they weren’t super effective there either. A fun alternative universe would be Apple buying Be, Apple going bankrupt or eaten by the clones, NeXT powering the internet with WebObjects, Microsoft crushed by antitrust and we are all running Linux using Eazel/GNOME.

Yeah it's interesting how similar what happened with Palm OS 6 was to Copland. They had a working, but outdated OS that had been hacked onto a new platform as a stopgap, then they couldn't get the rewrite meant to take full advantage of the new hardware out the door. Palm OS 6 was at least finished, but it never got used on a shipping device. There's an interesting Reddit post going over how the OS design was fundamentally flawed when combined with the ARM processors that were available at the time: https://www.reddit.com/r/Palm/comments/1422bqy/palm_os6/jn5o...

Palm at one point was talking to Symbian about licensing the Symbian kernel for the Arm PalmOS.

I wish that had happened... it might have saved both companies.

Best example of how far BeOs fell short was that for a very long while it lacked printer drivers of any kind --- by contrast, not only did NeXTstep essentially get printing "for free" since it used Display PostScript, the implementation of that was such that Adobe demanded a modification to the user agreement limiting the output resolution so that print shops would not be able to purchase NeXT computers and use them as RIPs for imagesetters.

Ah, Adobe, how I want you to burn in an enormous, abyssal hellfire.

Pre-standard C++ is an even worse programming language than C++ 98, but also the big difference wouldn't have been the technology, it was the people. If Apple buy Be Inc they're getting JLG back whereas if they buy NeXT they get Jobs back.

Jobs is what makes or breaks Apple in that critical period. I didn't like him but that's relevant to the success of the company. JLG did not have whatever it was Jobs gave the company.

And Jobs brought an entire team of people with him. Many of the top people at Apple got replaced by people from NeXT. Avie Tevanian, Craig Federighi, Bertrand Serlet and many lesser known names came from NeXT. The joke at the time was that NeXT bought Apple for -$400M.

Yes, the reverse acquisition. Minor correction though, Craig didn’t show up until much later. He missed out on some very tough years and came on when Apple was fully revitalized and printing money. I might even suggest what I consider the decline of Apple software occurred when Avie and Bertrand left and Craig took over.

I was amused to recall this a decade later when, as a result of Disney acquiring Pixar, Ed Catmull and John Lasseter were put in charge of Disney's animation studios and Jobs got a seat on Disney's board of directors as its single largest shareholder.

I recall the C++ "fragile base class" problem already starting to rear its ugly head by the end. Existing base classes couldn't be reasonably extended without breaking compatibility with existing applications, and the BeOS API was routinely designed in a way that promoted subclassing. e.g. to implement a window, you'd subclass BWindow and fill it with your own subclasses of BView. It's difficult to see how they would have dug themselves out of this hole in the long term. Perhaps eventually they would have needed to ship multiple versions of their system libraries corresponding to each ABI breakage.

For release 4, we added private impls with many many virtual declaration placeholders. I still remember the comment in every file: Mmmmmmm, stuffing!

So, exactly like what Mac OS X did with IO Kit. They managed for several decades...

There were other issues too, no? They went all in on multi-threading of the GUI which is super hard to do well, so apps were often crash prone.

I'm not familiar with Be API, but I did a lot of GUI dev in Java Swing back in the day. It's not that hard in principle, you launch whatever background op in whatever threads you like, and any GUI updates have to be done by sending messages back to the GUI event thread (or something like Swing.invokeLater(closure)).

IIRC BeOS gave every window its own thread rather than have one GUI thread per app. So in effect every app was multi-threaded by default.

Yes, Be GUI is heavily multithreaded, so core dumps were kind of common, and stuff like Swing.invokeLater(closure) only came later in Swing, after existing for a while as community library, after folks having the same issues in Java GUI applications.

Note that on Android they took an hammer solution, programming patters to invoke such code on main thread, have as outcome that there are either lint compile errors, or platform killing the application, for those flows not verifiable at compile time.

Yes, and it’s been a quarter century or so but this is how I remember BeOS doing it. Every window got a dedicated thread for handling events and GUI updates, and other code would communicate with it via message passing. The OS had a standard message passing system that was pervasive; if I remember right every thread got a mailbox by default.

But it was 90s era C++, so probably that was all just a polite agreement and the reality was that circumventing the message passing to directly call methods on objects that belong to other threads was common, and just as likely to happen by accident as on purpose.

> Swing.invokeLater(closure)

Should be:

   SwingUtilities.invokeLater(closure)

One minor correction: the Haiku developers worked some magic with GCC binary compatibility and modern Haiku builds are done with a modern GCC yet still preserve the ability to run and interoperate with software built using the old release which is important for preserving the use of commercial software built for BeOS without released source code.

Gee, maybe Linux devs could learn something from them...

This is not quite correct as I understand it.

32-bit Haiku can run old Be apps, but must be built with ancient GCC.

64-bit Haiku is built with modern GCC but it is not binary compatible with old BeOS.

Correct, yes. You can run BeOS apps on 32-bit gcc2 builds.

This is a surprising amount of effort to not break compatibility ;-)

You're right and I misremembered slightly. Still ABI magic in my book!

It was reported that Apple offered $75M for Be and almost $500M for NeXT and in retrospect those seem like entirely fair valuations. One was a mature OS and the other was a demo of an OS.

JLG countered with a $100 million and I thought Apple offered Steve $400 million at first. There was a moment when Apple was just talking to us (Be) and Steve heard about it. Bummed.

> They also implemented the OS API directly in C++, which tied them to a specific C++ compiler

We paid Cygnus(?) millions for that. The multiple virtual inheritance needed for MediaKit was a real joy to get working.

I'll note that Mac OS X used a C++ ABI in the _kernel_....

Kind of, you will note that it is based on COM, exactly to prevent ABI issues.

Which is what Windows has been doing since C++ replaced C for most of the systems programming stuff, around Vista timeframe.

Not at all. IO Kit was raw, pure C++, with all the ABI consequences you must deal with (including fragile base class). Just go to see any header of any exported IOKit class to see what I am talking about.

There is no COM whatsoever, no IPC, no IDL, nothing, dunno where do you get that from.

I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.

> There is no COM whatsoever, no IPC, no IDL, nothing, dunno where do you get that from.

I get that from knowing my way around OS X, naturally it isn't Windows COM, rather shares many of the same ideas,

https://developer.apple.com/library/archive/documentation/De...

https://developer.apple.com/library/archive/documentation/De...

> I just find it funny to claim that C++ was even partially to blame for Be's demise, when Mac OS X since its first public release actually embraced C++ for a much more delicate component.

I think that those that use such argument tend to be on anti-C++ crowd, they forget that NeXTSTEP even had Objective-C++ as well.

This is still completely different to COM in both goals and implementation. If this resembles COM to you, then almost anything resembles COM.

This is just the part how they deal with forward ABI problems, and is exactly the same that Be was doing too, as I mentioned in an above comment: private impl pointers and "preemptive" empty virtual functions (Be calls it "stuffing", OS X calls it "padding").

Perhaps they're thinking of the CFPlugIn architecture, which is basically COM IUnknown without everything Microsoft built on top of it.

https://developer.apple.com/library/archive/documentation/Co...

Reply on news.ycombinator.com