BeOS Binary Compatibility

Forum thread started by red_devel on Wed, 2005-11-23 22:04

Hey- I'd like to get a clearer picture of this project's plan with achieving, and eventually breaking, binary compatibility with BeOS. The stated goal seems to be: achieve binary compatibility in R1, and then break it in R2 so the project can move away from using the outdated gcc 2.95.

I guess I'm wondering, what does achieving binary compatibility in R1 really accomplish? Sure, it will allow us to run legacy, closed source, BeOS apps for which there is no chance of having them recompiled. But then the platform for them will be left to stagnate once again. And, if there is no chance of seeing these applications recompiled, it most likely means the companies behind them have died, or given up the project-- so these apps, if not outdated now, will be soon enough. Any company still actively developing BeOS software would most likely put forth the effort to recompile, no?

It seems that some sacrifices have been made to achieve binary compatibility, and it seems that for R2 the project will have to spend time going back and fixing these. Am I missing the reason why binary compatibility is a goal?

Also, what is yT doing in this respect. I read that the next version of Zeta will come "equipped with gcc 4". Does this mean they have broken binary compatibility? Do they plan on doing so? How much have/do they give back of the gcc4 port to this project?

thanks

‹ Waltercon T-shirts dual boot ›

Comments

Re: BeOS Binary Compatibility

by umccullough - 2005-11-23 22:44
red_devel wrote:
I guess I'm wondering, what does achieving binary compatibility in R1 really accomplish? Sure, it will allow us to run legacy, closed source, BeOS apps for which there is no chance of having them recompiled. But then the platform for them will be left to stagnate once again.

I wouldn't say that's necessarily true - I'm sure SOMEONE will continue to maintain R1 if they deem it necessary... and if it becomes unnecessary, then yes - it will stagnate and go unused.

There already are some areas where binary-compatibility has been thrown out the window either because the features were not used enough, not documented thoroughly, or internal to the OS anyway.

Since I'm not one of the admins, or anyone who truly knows the roadmap - that's about all I can say at this point.

BeOS Binary Compatibility

by Benjamin Mullins - 2005-11-23 23:25

Yeah... there's no reason that R1 could not be maintained by interested people as a seperate branch of Haiku. That's the beauty of open source, after all.

That being said, I don't really know either. I think the main idea is that, with binary compatibility, Haiku will come out of the gate with support for a lot of applications. This way, Haiku can build up enough of a userbase that it'll be more attractive to recompile for R2, and more likely for people to go to the bother.

But that's just my assumption. I don't actually know for certain.