Antique BeOS Content by Scot Hacker (2011)

Re:Antique BeOS Content by Scot Hacker (2011) by allenbrunson on Monday January 15, 2018 @11:28PM (#16155827)

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.

[ Parent | on HN ]

Re:Antique BeOS Content by Scot Hacker (2011) by memsom on Tuesday January 16, 2018 @05:05AM (#16157030)

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.

[ Parent | on HN ]

Re:Antique BeOS Content by Scot Hacker (2011) by allenbrunson on Tuesday January 16, 2018 @05:39AM (#16157178)

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.

[ Parent | on HN ]

Re:Antique BeOS Content by Scot Hacker (2011) by memsom on Tuesday January 16, 2018 @05:51AM (#16157244)

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...

[ Parent | on HN ]