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.

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.

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.

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.

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.

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.

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

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.

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.

The counterpoint is RISC OS for GNOME.

GNOME 3 was trying to built a clean modern minimalist desktop without all the clutter inherited from the design of Windows... But all they know is, very visibly, Windows and KDE.

RISC OS is that clean legacy free desktop. It's unlike anything else, built from scratch by a team not interested in what the rest of the world was doing.

And it's still alive and still updated and works well on modern hardware. Several separate efforts are building 64-bit replacements today.

> I wish that there was some edict from KDE Project management telling everyone working on the Plasma desktop to spend a week in Haiku or something.

The other thing is that it says right at the start of the BeOS Book - and this is carried across to Haiku - is that you shouldn't have a spinner or hourglass. It should do *something*, it shouldn't make you wait.

Mmm. Or improve the OSes themselves.

At this point, they could likely decompile MacOS classic and rework it to give it modern memory protection, virtual memory, preemptive multitasking, and networking.

I assume booting an OS with a mere few megabytes of RAM footprint would only take milliseconds?

Last time I tried it on my old Thinkpad T440, it ran fairly well. Now with Firefox it's a serious contender for an internet machine.

Haiku made them magnetic. In classic BeOS you had to manually position the windows on top of each other, then hold shift and manually drag the tab over from the left. And they wouldn't be tethered together: moving one window wouldn't move the other. It was annoying enough that I never bothered. By the end of BeOS's life I was mostly using the Mac OS 8 titlebar style (accessed by holding down all the modifier keys and pressing the Be menu).

> I haven't seen anything like it

I remember using the fluxbox wm like this back on the university Sun machines

It would just stack the windows of different sizes, so if you hit the Winamp tab the smaller Winamp tab would be at the top of the stack. Pretty simple and intuitive.

I loved the tabs on BeOS.

Damn, I spent some time getting Opus 5 to do this for Mac, being proud of discovering a new UI metaphor - bringing a set of workflow related windows into one “tabbed meta-window”.

Good work everyone who made this for Haiku.

I wrote something to do this 13 years ago, someone picked it up after 6 years of inactivity (since I don't own a Mac anymore): https://github.com/justjake/metamove

How funny, this is exactly the control scheme I ended up with for a window-manager-esque system I was working on recently. I love finding out I've rediscovered something proven to work well :)

Yeah I do this too, though on macOS (through Rectangle, the window manager). Control+Option drags the window under my cursor. I picked that up from the Super key drag on Linux

For Windows there is AltDrag or the AltSnap fork.

https://github.com/RamonUnch/AltSnap

https://github.com/stefansundin/altdrag

> I really like the linux solution here. My windows have no titlebar/borders at all. To move a window hold the window key and drag the window from anywhere, to resize hold the window key and right-click drag.

Speaking of which. It is not a Linux solution but stock X11 twm window manager features dating back into 1988, i.e.:

  NoTitle

  BorderWidth 0

  Button1 = m4 : window : f.move

  Button3 = m4 : window : f.resize

[0] m4 stands for the Mod4 modifier, now commonly assigned to the Super/Windows key. The equivalent 1988 configuration would have used m (Meta), since the original binding syntax supported Shift, Control and Meta only.

Still got my BeBox, boot it up every year just to make sure its still okay. I have wondered about that paint job over the years ..

I was going to say this as well the GeekPort was a parallel port. I always thought it was marketed that way is that Macs didn’t have a parallel port. Having a parallel port would make the spec sheet seem regressive. I believe serial ports were always faster than parallel ports. I bought a BeBox at the time.

The original Nike store in NYC purchased one to do their signage media playback. It didn’t go well.

This is still an on-going thing for the LinuxCNC project (which mostly follows Mach3 in using a Parallel port interface to drive a CNC controller).

I think so; it's been a while.

I seem to recall that you could hold down Alt key and drag the tab horizontally. So a tab could stick up anywhere along the top of the window frame. The SPARCStations had three-button mice, and this might have been mapped to middle or right mouse button.

The tabbed interface features the ability to gather windows into tab groups. So when you are moving a window by dragging its tab, if you drag the tab next to another window's tab, the dragged window will snap to that other window's frame, the dragged window will be the selected tab and its contents displayed in the frame. Then dragging any of the tabs drags the whole set of tabs that are snapped to that frame. Click on a tab to make it the active tab displayed in the frame.

It's effectively like tabs now, but sort of inside out: tabs are managed by the windows manager and not the app. Tab groups of multiple, different apps. The app does not have to be "tab-aware" to be in a tab group, although I suppose there are events that can signal the manager to make a window the selected tab. It's just raising a window, making it frontmost. Modal dialogs can get tangled up, but it's no worse than the mess commonly accepted today.