upvote

points

by sfblah14 hours ago |
comments
upvoteby ndiddy14 hours ago|
next
[-]
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.

reply
upvoteby WillAdams12 hours ago|
parent|
next
[-]
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.
reply
upvoteby diskzero10 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby ndiddy8 hours ago|
parent|
[-]
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...
reply
upvoteby tialaramex13 hours ago|
parent|
prev|
next
[-]
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.

reply
upvoteby smithbits10 hours ago|
parent|
[-]
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.
reply
upvoteby diskzero7 hours ago|
parent|
[-]
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.
reply
upvoteby electroly7 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby mike_hearn2 hours ago|
parent|
next
[-]
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.
reply
upvoteby hobo1232 hours ago|
parent|
[-]
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)).
reply
upvoteby diskzero7 hours ago|
parent|
prev|
[-]
For release 4, we added private impls with many many virtual declaration placeholders. I still remember the comment in every file: Mmmmmmm, stuffing!
reply
upvoteby timschmidt10 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby lproven1 hours ago|
parent|
next
[-]
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.

reply
upvoteby ErroneousBosh36 minutes ago|
parent|
[-]
Correct, yes. You can run BeOS apps on 32-bit gcc2 builds.

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

reply
upvoteby hxorr2 hours ago|
parent|
prev|
[-]
Gee, maybe Linux devs could learn something from them...
reply
upvoteby wmf13 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby diskzero10 hours ago|
parent|
[-]
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.
reply
upvoteby diskzero10 hours ago|
parent|
prev|
next
[-]
> 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.

reply
upvoteby AshamedCaptain10 hours ago|
parent|
prev|
[-]
I'll note that Mac OS X used a C++ ABI in the _kernel_....
reply
upvoteby JKCalhoun9 hours ago|
prev|
next
[-]
Designed in California has been a very entertaining (video podcast) watch that covers this era:

https://www.youtube.com/@designedinca

(Specifically they talk about Be beginning: https://youtu.be/5IFxwnXASyQ)

reply
upvoteby pjmlp13 hours ago|
prev|
next
[-]
They probably would fail to recover and be another historical company by now.

If not, desktop computing would be taken over by C++ as main systems programming language, and UNIX like computing relegated to servers.

reply
upvoteby tialaramex13 hours ago|
parent|
[-]
Outside of the GUI, Be is a very thin veneer over Unix. There is, no joke, a class named "BStatable" which, if you know some Unix, is just stat, because of course what their OS kernel implements is just stat.

In the places where there's something entirely different going on, such as networking in earlier BeOS, it's trash and you'd obviously want to throw it away and do what Unix did - Be were doing so. So a hypothetical turn of the century fruit-flavour BeOS is probably much closer to "Unix with a different UI" than you're thinking. NeXT changed nothing there.

reply
upvoteby pjmlp13 hours ago|
parent|
next
[-]
It certainly wasn't on the BeOS R5 CD that was available back in the day, or the whole Kits available for BeOs programming in C++.

The amount of work done by Haiku to provide a proper POSIX userspace support proves the point.

reply
upvoteby diskzero7 hours ago|
parent|
prev|
[-]
A strong BeOS selling point was that it was POSIX compliant. I guess that is what you mean by a thin veneer. But we had to write all that code; it wasn’t like we were running Linux or some SCO or other flavor of Unix. It was a written and rewritten and rewritten multiple times.
reply
upvoteby tialaramex17 minutes ago|
parent|
[-]
I am greatly enjoying the juxtaposition of a comment asserting that obviously BeOS was so far from POSIX that Haiku had to do loads of work to get there and your comment that BeOS was POSIX compliant.
reply
upvoteby walrus0112 hours ago|
prev|
[-]
It would have been a disaster, BeOS was significantly different from a NeXT/BSD-like unix type base that made it relatively easy for software to be developed on MacOS in the 10.0 to 10.4 era. Early versions of MacOS X like 10.0 were clearly just an evolved NeXT with a cute MacOS finder like skin on top.
reply
upvoteby diskzero8 hours ago|
parent|
[-]
Well, not only former Be but former Finder developer here. The OSX Finder was certainly not a cute Finder-like skin, it was in fact huge amounts of the OS9 Finder source code including a complete copy of a modified Metrowerks PowerPlant C++ framework underneath it all. There was even elements of the old MacApp framework there. It was not a skin; it was a source code behemoth with massive amounts of legacy code.
reply
upvoteby lproven1 hours ago|
parent|
next
[-]
That is amazing to read. I never knew. I thought it was Workspace Manager, adapted to feel more Mac-like. There is even a clear line of descent:

1. The Rhapsody developer previews, which are NeXTstep with a menu bar at the top and desktop icons, and a Platinum skin.

2. Mac OS X Server 1.x which has cascading finder windows, an icon view by default, and some other things much like that.

3. Mac OS X 10.0, which I used, or tried to use, as a daily driver, with a broadly Mac-like experience with an Apple menu, but with app names next to it containing global "about" and "quit" options, and so on.

It never did acquire any of the nice stuff that came in with System 7 (e.g. drag-and-drop customisable Apple menu stored in folders in the System Folder) or MacOS 8 (e.g. folder drawers that shrink to tabs).

reply
upvoteby walrus012 hours ago|
parent|
prev|
[-]
I didn't mean that the 10.0 finder was a reskinned NeXT GUI file management application (as you point out, it clearly wasn't and was a huge thing that had a bunch of heritage code), but that the entire 10.0 GUI was a kinda-MacOS-9-like GUI on top of the NeXT bsd-heritage unix-like base. If you were to take a 10.0 system and put it side by side for comparison with the CLI environment perspective, file tree, system libraries with the last NeXTSTEP releases or rhapsody.
reply