The BeOS internal architecture changed a lot from release to release. The kernel, file system, all the kits were constantly undergoing massive change and I don'

The BeOS internal architecture changed a lot from release to release. The kernel, file system, all the kits were constantly undergoing massive change and I don't think there was an ABI until release four. We broke binaries all the time! Most of the code wasn't open sourced, but it leaked and yellowTab released a version using the actual BeOS source code. The entire system compressed down to 90MB and you could ftp all.tgz and build the whole system. Looking at the architecture critically, is it a good idea to have a C++ API and have to deal with fragile base classes? I remember stuffing classes full of placeholders to create space in the vtable for future changes. BeOS was well documented and the BeBook is still nice to read. Looking at the Haiku source, I see that they have all the kits, with the same API. When I look at the source for Looper, the code is a shadowy reflection of the "real" source. It may even be much better! If Haiku feels good to use and program, then I think it is faithful to BeOS. Cyril was constantly improving the kernel, Dominic was constantly improving the filesytem, Benoit was constantly improving the window server, Pavel was constantly improving Tracker, etc. There wasn't really a dogma about what BeOS should be except fast, responsive, forward looking and fun for users and developers.