3 ms·

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

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