>>OBOS is only guaranteed to be source compatiable. >> >>I think that the chances are less than 10% of us getting binary >>compatability in R1 of OpenBeOS. Maybe we will eventually in OBOS R4 >or >>5, but don't hold your breath :) > >I think we have about a 90% chance of being binary compatible with R5. >It's what we're shooting for and I'm increasingly convinced we'll do >it. > >However, only R1 is concerned with BC. OBOS R2 is guaranteed NOT to be >BC compatible, let alone R3, R4... I am not sure that this is even true. I don't want to promise that R2 WILL NOT BE backward compatible until we show that it won't be. Let's take a very hypothetical case - we rename all of the libraries (like Nathan wants to do). What if we left all of the R1 libs around? So long as we invent new server hooks for new functionality, maybe R2 would allow R1 apps to work. I WILL NOT guarentee that R2 should run R1/R5 apps. But I don't think that we should rule it out, either, until we have a good reason to break that compatability. :-) But, as usual, R2 discussions >> GE. >You gotta realize something here: OBOS is really a new OS in the >making. Using BeOS R5 as the target allows us to have a stable target >for the initial implemenation. After that, the OS will grow, change, >and evolve, like any other software. Binary compatibility with R5 is >only a "hook" that allows us to reel in the current BeOS users. We risk >alot if we're not able to fashion that hook. But once we do, we can >bring everyone forward with us. > >