I vividly remember being in an airport when this announcement hit the news, waiting to catch a plane to go home for the holidays. And thinking "huh, bad move, they should have bought Be instead."
What can I say, nobody's perfect :-D
What can I say, nobody's perfect :-D
I still can't remember the technical merits of the Be operating system. Someone tried to get me to use it back in 1999, but there were no applications worth using.
Because the Unix nerds told them that if they wanted a rock solid workstation OS to replace legacy-MacOS (which was getting very long in the tooth at that time), it would be a good idea to have something BSD/NextSTEP based rather than whatever BeOS was.
If you look at OSX v10.0 it's pretty obvious that it's NeXTSTEP with a MacOS-looking GUI slapped on top of it. They've been incrementally upgrading and developing it since then.
BeOS was very interesting, but one thing it was not was anything close to a BSD/Unix platform.
Rhapsody is pretty interesting stuff.
EDIT: Missed the link. http://rhapsodyos.org/
You are quite correct that NeXT was undoubtedly, upon close inspection, the ‘superior’ OS (UNIX lineage, stable, multi-user, etc.) but as a user (and sometime programmer) it wasn't that evident: my relatively cheap dual-604e BeBox outperformed my dual PentiumPro NeXT machine by a significant margin, or rather, felt like it did because the “pervasive multitasking” made the system extraordinarily responsive, and the lack of legacy code and backwards compatibility definitely kept the system snappy and lithe. Multi-user support didn't really change much from the user perspective either, as security was something of a remote concern and running any kind of ‘server’ on one's desktop was pretty exotic. BeOS was POSIX compliant to a degree such that many people still (erroneously) believe that it is a Unix or Unix-like, and you could run all the open-source command line tools you could possibly want. The BeFS filesystem's metadata capabilities were extraordinarily, and I liked both UIs equally (the etched vs. graffiti aesthetic legacy has etched itself into my neural circuitry), but probably NeXT was more innovative in terms of user interaction and rendering model whereas BeOS basically aped Windows and Classic MacOS quite closely. NeXT's development tools and environment were clearly superior. It was comparatively a resource hog.
So yes, there was a technical edge, and probably knowledgeable influencers at the upper echelons of power probably recommended as such. But at the time I had the feeling that Jean-Louis Gassée (the founder and CEO of Be Inc.) significantly overplayed his hand, and made ridiculous demands because he thought he had Apple cornered by virtue of their failed OS development attempts, growing obsolescence, and perceived lack of serious alternatives. There's the diffuse feeling that Gil Amelio (Apple's then-CEO) eventually grew weary of batting back the demands and started looking for apparent alternatives just as a means of introducing some competition to the negotiations, and eventually the plonked for NeXT much to everybody's surprise. He even made a droll remark about “choosing Plan A rather than Plan Be” or something to that effect. All things considered, it was a very counterintuitive decision, mainly because NeXT had such hefty resource requirements and we hand't quite yet absorbed the implications of Moore's Law (or rather, were used to Microsoft squandering any and all increase in hardware performance with increasingly inefficient code, leading to no perceivable improvement year over year). Amelio deserves more credit for having seen through all of that and made a brave, surprising, and obvious-only-in-hindsight decision that favoured a mature, stable, and extensible platform.
At the time I felt it was an utter mistake, but I was fourteen, and pretty ignorant of the ways of the world. I think history speaks for itself. Amelio deserves more respect for the decision he made, because it was ultimately his decision that led to adopting the superior, extensible technology, and of course brought Steve Jobs back on board (who promptly stabbed him in the back and ousted him in a boardroom coup).
I had a brief flirtation with Windows NT4/2000/XP in 1999-2003, but then I switched to OSX 10.2 on a dual PowerMac G4 and have never looked back since. Only of late have I started to feel that as Apple's focus has switched to iOS on mobile devices they've started to let their development effort and quality control really slip to borderline-unacceptable levels. I can understand that OS X is no longer the enabler for high-margin computer sales it once was, and that that role has passed on to iOS, but OS X (macOS of late) is the platform where the apps that form the bulwark of the iOS ecosystem get developed. Apple really shouldn't let the desktop OS languish or endure the kind of high-profile mishaps that have occurred of late.
> I was fourteen
Wow. What's the story behind that?
It’s kind of an odd story, my use of ’work’ needed some explaining but I thought it would slow down the discussion to go off on a tangent lot narrate this story.
The catch is that it was much less mature. It was single user and had very little real security. It had basic Posix support, but NeXT has much more rich BSD-ishness.
This sorta-kinda worked for things like Linux where the masses would crowdsource them, but for a commercial OS like BeOS they had to spend a ton of time working on this instead of the actual OS.
My recollection at the time was as soon as they entered into this phase the forward progress on BeOS itself ground to a halt, and within a few years the mainstream OSs had started to at least pay lip service to its key features. Any momentum they had was completely lost.
Or in the case of UNIX vendors, outsource their development costs.
Want an MP3 player? Don't need to open the files and get their ID3 tag info, it's in the file system. You can query it with "filetype:mp3 artist:bach" or whatever and you'd get a list, updated when other songs files were added or changed, of all mp3s meeting your requirement. Same for any other document. Contacts can be stored the same way, rather than hidden away inside an arbitrary file format you can store them with each bit of info as metadata (query on the phone number and find everyone associated with it), email, anything. The real benefit of this filesystem-as-database approach was that it breaks the data silo situation you find in many (most?) other OSes.
Downsides were the dearth of applications, being single-user, and for a time being PPC only. Opening it to x86 opened it up to many more users, but then the OS became the product (instead of the BeBoxes they also sold) which was much lower price and profit. It was a POSIX-compatible OS (good), but not really a Unix in the way users of Unix would expect. This did make porting of applications a bit easier, though.
They were also crippled by Microsoft's actions with Compaq (HP?), where MS threatened to change the favorable licensing costs for MS Windows if they sold BeOS on their computers.
Since things were then just ported to Be rather than written directly for it, it kinda felt like POSIX compat was Be in its death-throes.
I bought in at R3/3.1, and I regretted it since as it was just a sad slow slide after that :(
BeOS is a really neat little OS. I like it a lot, I often wonder how different things would be if they had taken that direction.
Basically, AmigaOS 1992 was a more advanced operating system than BeOS 1997. Pity Commodore completely squandered their opportunity and Windows 95 killed them dead.
This was part of why the graphics felt so flippin fast: appkit just wrote to the GPU & framebuffer itself. No need for any context switches.
That's incorrect, AmigaOS had been fully preemptively multitasking since Kickstart 1.0, in 1985. It took Windows ten years to get preemptive multitasking and Mac even longer.
You are right that AmigaOS never got protected memory, though.
NeXT's ABI interfaces (C and ObjC) were and are much more stable.
(I'm not saying don't use C++, just don't use C++ and expect a stable binary API. You need to wrap it in a C API instead unfortunately. There's too much magic in C++ to have a stable ABI and still be able to evolve the language.)
Symbian was written in C++.
Any others?
C ABI only happens to exist on OSes written in C, thus having a C ABI at all.
NeXT used Objective-C on its drivers framework, and that was replaced by a C++ subset in IO Kit.
Likewise their Metal shaders are based on C++14.
Microsoft has been slow and steady migrating their code into C++ since Vista.
https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...
Symbian, GenodeOS, includeOS, mbed are all written in C++.
IBM mainframes were written in PL/I dialects, like PL/S and PL/8, and new code is written in C++.
ChromeOS is written mostly in C++, even if it exposes only Web APIs.
Most of Android native libraries are written in C++.
Of course on ChromeOS and Android, C is still there given the Linux kernel.
That's exactly what happened to BeOS and Symbian. Both were stuck at GCC 2.95 for many years after mainline GCC was already at version 4.x.
There's a ton of C++ in macOS/iOS, but it's wrapped to plain C for the public userland APIs.
Other C++ OSes are doing pretty ok.
Symbian's inability to upgrade the platform to modern compilers definitely was one factor in its failure to gain developer mindshare, and the C++ ABI was the reason for that. They had painted themselves into a corner with a '90s C++ embedded dialect and had no easy way forward.
I'm curious -- which modern OS exposes a C++ API and is "doing pretty ok"? I can't think of any.
Migrating to a new C++ ABI wasn't in any way related to Symbians downfall, internal politics were.
As for OSes ARM mbed, Windows all new APIs since Vista are based on COM specially anything UWP related, GenodeOS, Arduino bare-metal libs, IncludeOS.
"Unlike C++, COM provides a stable application binary interface (ABI) that does not change between compiler releases.[3] This makes COM interfaces attractive for object-oriented C++ libraries that are to be used by clients compiled using different compiler versions."
The others seem to be mostly embedded kernels or unikernels which will be tightly linked into your code anyway, so there's no issue of ABI incompatibility with those.
COM is built on top of C++ VTBL implementation on Windows, UWP extends COM by supporting generics as well.
As for the other OSes, it is irrelevant where they are used, the fact is that they are exposing C++ APIs not C ones.
As matter of fact, had GNU/Linux not taken over the OS world and FOSS projects, and C would be pretty much history by now.
Mac OS, BeOS, Symbian, OS/2, Windows were all adopting C++ APIs when GNU/Linux started to gain adoption, with its manifesto to focus on C for GNU software.
There is no major C++ compiler on a major OS that provides a stable ABI, so that's what people mean when they say there's no stable C++ ABI.
COM is independent of the Microsoft C++ compiler. It's defined on top of the platform's C ABI. (There's a COM implementation on Mac, for example.)
On Windows, COM uses the stdcall calling convention. There's no trace of C++ there.
[1] Pun very much intended, I'm afraid.
Gil Amelio thought the 20th Anniversary Macintosh was really awesome and clones were a good idea.
With (seriously cash strapped) Apple doubling down on Multimedia on rebranded BeOS as a licensed OS for Clones, they would have gone head-to-head with the entirety of the PC market that already had a taste of BeOS.
BeOS was quick and fun, but barely had a TCP/IP stack. See BONE.
Apple probably would have switched to Intel earlier.
(I had an amateur radiotelescope wired up to the GeekPort and exposed the controls over HTTP. I’ve long since retired that setup in favour of a modern SDR linked to a Raspberry Pi 3.)
I had both BeOS and NeXTSTEP and pretty much left BeOS to sit while NeXTSTEP was my daily driver (along with a Windows NT machine because IBM was problematic with OS/2).