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?
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.
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.
Sorry for reviving such an old thread, but the subject title is exactly what I’m inquiring about.
Could somebody please explain exactly what is meant by “BeOS binary compatibility” as it relates to the Haiku project?
Does it mean that any application that previously ran on BeOS R5 will also run on the gcc2 hybrid Haiku builds? How about applications that are closed source, and for which no source files are available?
Currently, there are a number of applications which were included in the BeOS R5 or R5 Pro distribution, which when copied to Haiku will not run. There are also several closed source applications which fail to run on Haiku as well. Can these be fixed? If so, can we use this thread to track these issues?
Hello vidrep. “binary compatibility” means that Haiku could run BeOS software, without need of recompile it. So, even “closed source” apps can be used in Haiku. In my case, I use SoundPlay, CLAmp, Lingua, GoBE Productive and more “BeOS Apps” without any issues in Haiku.
Of course, there are some apps that not works under Haiku. Some of them, because issues in the Haiku code; another because the BeOS app uses some non-standard or undocument calls to the S.O. (for example, SoundPlay 4.9 https://dev.haiku-os.org/ticket/7631), or also, because uses some hard-coded paths (example, /boot/beos/…).
If you have some app that doesn’t work in Haiku, please use the track to open a ticket, so the developers can check if there are some issue in Haiku code, or at least, found some “trick” to get the app work again.
Include a link to the application or, if possible, attach it to the ticket directly
Check that it actually runs on BeOS if you can (sometimes we get reports for apps that only ran in old versions of Haiku but never ran on BeOS, or apps designed for BeOS R3 or R4 only)
Attach a debug report if there was a crash, attach relevant part of the syslog in other cases
To get exactly the relevant part of the syslog I do this:
tail -f /var/log/syslog
then run the app, and copy the output from that terminal. It should include missing symbols and other similar problems.
Check if running hte app from Terminal helps, and if it prints something useful there.
If you test multiple apps, try to analyze the errors and group the apps together (missing the same symbol, crashing with similar backtraces, etc). Usually this would mean a single fix would be good for multiple apps.
If the source for the app is available, sometime we will decide to fix the app itself instead of fixing Haiku. Or, for things included in the BeOS CD, we may decide to rewrite it. In both cases, this is because some apps did not do things "the right way" and providing exact bug-for-bug compatibility with BeOS would break more recent apps. Or sometimes there is a tradeoff, for example the antialiasing in app_server creates some drawing issues in some BeOS apps.
Since we plan to switch to 64bit and/or gcc4 someday, it is our interest to get the apps open sourced and fixed, instead or at the same time as getting them running with the old binaries. This is what the HaikuArchives project is doing. We had some success with reaching the authors of old apps and getting them to share their sources.