So - firstly, nice idea.
BeIA was more than just a skin on top on BeOS. They did a lot of stuff under the hood too.
-
The Wagner (Opera) Browser was a full screen replacement for the desktop. The user was not ever meant to see Tracker or Deskbar. It was possible to get to them, but only if that feature was enabled in the image.
-
The file system used was not BFS. It was something called CFS, and it was compressed. The file system took up way less space because of this.
-
The executables in a release system were “crushed”. Every single exe was run through a one way process where it has a bunch of code removed and added to a common look up table (a crushed dictionary) and had the physical magic number in the exe changed from “ELF” to “CEL”. This further reduced the footprint. A crushed system with a fullish BeOS install could fit on an 8MB CF card (YES, 8 MEGABYTES!) The kernel knew how to load and execute crushed builds. It would do one or the other, and an uncrushed system would fail to run crushed exes and vice versa. This made BeIA very difficult to extend from and end users POV…you needed un uncrushed build or to be able to crush using the same dictionary… I doubt the plan was ever to allow end users to add executables.
-
The Binder system was used to communicate between the apps. Apps could be embedded like COM objects in tot he Wagner browser window.
-
Everything, and I mean EVERYTHING was done through Wagner. The user saw nothing of the BeOS UI, save when controls were embedded in pages. All of the controls were styled like those in Dano, so if you look at those controls now, they make a whole load more sense because they were designed to look good embedded in a browser, not necessarily just for the OS.
You can probably recreate some of this… but you’d end up with a mega system, compared to the mini system you’d get in BeIA land. It would be quite a pale shade of what BeIA was and what it was capable of.