3 ms·

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 fo

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 :)

allenbrunson 9y ago
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.
- memsom 9y ago
  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.
  - allenbrunson 9y ago
    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.
    - memsom 9y ago
      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/BeOS/strokeit_src https://github.com/memsom/ratcowsoftopensource/tree/master/B...

allenbrunson 9y ago

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.

memsom 9y ago
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.
- allenbrunson 9y ago
  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.
  - memsom 9y ago
    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/BeOS/strokeit_src https://github.com/memsom/ratcowsoftopensource/tree/master/B...