I worked at Be for almost a year, and used BeOS for a couple of years before that. I am not an expert, but I can mention a couple of things.

The biggest one was: freedom from backward compatibility. You can't comprehend how much cruft you are drowning in, in your typical OS, until you are free from it. Coming to BeOS from Windows, as I did, it felt like 2,000 pounds was lifted off my shoulders.

BeOS was free to fully embrace some modern technologies that had been bolted on to older operating systems as an afterthought. The biggest one was multi-threading. Having spent years on earlier operating systems, I can say that all of them have a stunted idea of multi-threading, compared to BeOS. Typically, you are forced to run your user interface in your main thread, and you have to run background tasks in background threads, and invent ways to communicate between the two.

Contrast BeOS: every single window runs in its own thread. Think about that for a minute: If you write a BeOS app that has two or more windows, surprise, your app is multi-threaded. Whether you like it or not! A lot of programmers, coming from older operating systems, very much did not like it. Personally, I came to embrace this as BeOS' greatest strength. Communicating between windows was pretty natural: just drop events into each other's event queues, which were of course thread-safe.

Unfortunately, the early architects of the system made their own set of poor decisions that led to a new round of cruft. The worst of these was tying themselves to the ABI of a particular C++ compiler. GCC version 2.9x, I think. In the last year of Be's existence, we were really feeling the pain of this. The compiler we were shackled to was many years out of date. If we switched to a modern compiler, it would have a different ABI, and all older software that couldn't be recompiled would have been instantly broken. Nonetheless, there was a vocal minority of engineers inside Be who argued for doing just that. We weren't focused on external users at that point, just internet appliances, so we could have gotten away with it. But we were all BeOS users ourselves, so we would have lost a lot of useful apps that way.

This comment is such a perfect example of the reasons I come to read the comments here on HN. Thank you for the info.

Could there not have been a compromise for those devs who didn't want ABI compatibility? For instance with Apples handling of Mac OS apps and then carbon and then cocoa?

Meaning, some sort of optional emulation layer? Of course, the system architecture may be so different as to make it impossible, OR the business decisions needed at the time couldn't afford a middle layer.

Either way, this was one of my favorite comments on here, so thank you :)

I suppose it would have been possible to build some kind of API shim that would allow for two or more ABIs. Alas, the technical details of how to make that work are above my pay grade. I can say that it never came up in the heated debates I heard inside Be. Possibly because that would have meant the base OS would have been a lot larger, and we were targeting resource-constrained internet appliances at the time.

You could get a much fuller answer by exploring how Haiku handles this. I haven't paid much attention to that OS in quite awhile, but I think they did indeed succeed in keeping a set of backward compatibility libs, for older software, and also built a new set of libs for recently-compiled software.

BeIA was quite clever. The OS compressed the binaries by using a one way (?) process to pull out common code segments in to a common dictionary. The OS then read that code somehow in to memory when the apps started. You could run the OS uncrushed, but it took up a lot more space. One could fit the entire OS on a 16MB CF card in crushed format. (YES, MB not GB!!)

The crushed apps have a magic symbol CEL instead of ELF in the file header.

The file system was also compressed. It was called CFS, rather than BFS (BeFS) and a lot of stuff like attributes and metadata was very broken in the pre 1.0 builds I saw.

I had completely forgotten about that "crushed" business, but you just reminded me.

If I am remembering correctly, we used uncrushed binaries and a non-crushing kernel while developing on our own PCs. (We used plain-vanilla garden-variety Intel PCs to develop on. Very few developers needed to interact with the actual BeIA devices.) The crushing part didn't happen until somebody on the build team was building the final binaries to go onto the BeIA devices.

Sometimes, the crushed build process wouldn't work! It was super finicky. That would prevent a test build from going out when it was supposed to, and the testers would have to twiddle their thumbs for awhile.

Other than that, I can't tell you much about it. I was a lowly application engineer. I didn't have to get into all the picky details about how the kernel interacted with apps.

Yeah, the tools I had were picky. The size of the OS partition was very specific - it had to fit on to a multiple of a CF card I think. There was some kind of hard limit of about 32MB or something like that. I know I had it all running on an old Compaq PC at one point, but the bootloader would only boot if it was the only OS on the drive, so that was a bit of a pain in practice. I probably still have the OS images somewhere.

I also know that the OS was a bit quirky in so much as some of the R5 API's were missing, or closer to the R4.0 ones at least. The File System was definitely flaky.

I started to write this app to do PalmOS style handwriting input for the DT-300, but I ended up selling it on to finance some other project before I finished it. https://github.com/memsom/ratcowsoftopensource/tree/master/B...

I guess the great intel compiler switch had already happened between the old PE based Metrowerks and the "new" gcc. I can vouch that stuff from PR1/PR2 still more or less runs under R5.03 on PowerPC (for example, I managed to get the Metrowerks Java implementation to "somewhat" work under R5.) But stuff from the R3 Interl relelease really just does not work on R4.0 Intel because of the compiler change. I guess if it was still ELF base, it might not have been so bad.

Question/observation - with the CELF (Crushed ELF) format, would that not have been enough to make moving the compiler either justifiable (you were crushing the EXE, so the format was different anyway), or impossible (the tools would need to be altered to handle the newer format)? I kind of think the former. I don't really know enough about how the apps were crushed (other than that it was a real PITA if your OS didn't have a map* dictionary* with the right symbols in it.)

* Been over 10 years and everything I learned I learned from hacking on BeIA after Be closed shop as an enthusiast, so forgive me if I use the wrong terms.