Backwards compatibility

What is preventing Haiku and Zeta from maintaining backwards compatibility with their R1 releases in R2? I know that FreeBSD has compatibility layers that let people run programs from all of the old versions of FreeBSD, and even Linux applications. How does it achieve this? FreeBSD uses gcc too, right? So its suffering all of the weird gcc abi changes as well.
Perhaps it would be possible to install an application compatibility layer, most likely as a directory somewhere, that would allow support for a different type of application? And to keep sizes down, they would be optional at install.
I don’t know how FreeBSD does it, and the languages I can program (Basic and Python) don’t have this problem. Would it even be possible to create support for different application types like this, by adding the required so’s somewhere? If so, this adds the possbility of full native-looking emulation, simply by adding a directory in the system containing a wrapper for, say, Windows binaries to run on Haiku x86, and possibly Haiku PPC with more emulation.
Is it possible? Because throwing away all of the old R5 applications at Haiku R2 because they are dead/closed source doesn’t seem to be all too smart.
–Walter Huf–

It’s actually not all that big of a deal IMO. One thing I’ve noticed is that most of the closed-source apps that are available are either abandoned or under active developement. The most important one would be Gobe Productive. As of R1, we could get away with not having Productive by making use of AbiWord and Sum-It while we wait for YellowTab to complete the port of OpenOffice. You could also use one of the AJAX-based word processors out there by way of FireFox. Once R1 is released, we should see a bigger trickle in of help into the community as Haiku will suddenly go from “vaporware” (which it really isn’t) to “legitimate” and “viable”.

Also, will Zeta R2 and Haiku R2 be compatible? Or will apps have to be compiled for each separately, similar to the way they are now? Will both projects use the same gcc and such like, at least?

Binary compatibility with Zeta is about as likely as Palm releasing R6. I don’t see why there won’t be source compatibility for the most part. There are disagreements on, for example, the implementation of Zeta’s Locale Kit and some other things, but considering that YellowTab uses quite a bit of Haiku code, I wouldn’t worry too much. As for GCC, YellowTab has donated a port of GCC4 to Haiku. Considering the tinkers in the community, it would not surprise me if we saw unofficial Haiku builds floating around which were built by GCC4.

This excites me, hehehe. Sorry
I’m sure that, with YellowTab including a link to in their browser releases, that people will discover a version of BeOS that they can contribute to. That will encourage more people to develop for Haiku, and that will make Haiku development go faster, and then Haiku will finally be released and people will orgasm, just like me, over the possibility of a simple and easy to use free operating system, which is sorta like Zeta except freeer.
Also, how much of Zeta’s/Dano’s ideas will Haiku implement? Theme-ing rocks, and the Locale Kit is cool, and probably a bunch of stuff that I didn’t even notice. What disagreements are there?
–Walter Huf–

Well, support for different window decorators is there already, like in Zeta. It’s just that the app_server is in a major state of flux, so the only one used right now is the one it has internally. There are decorators for R5 classic, Windows 98, and MacOS 8, and I will probably develop a few more. Localization is already started as a part of OpenTracker. As for other stuff, who knows?

Would it be possible to have binary compatibility kits?
Like, you install some files and you can magically run programs that were compiled specifically for Zeta?
Cause I’m thinking that after R2 is released and commercial developers start developing for Zeta and Haiku, they might not like to compile their programs for two or three or four different variations of BeOS. And since Zeta is currently the most widespread BeOS variant, they’ll probably only develop and build for Zeta. The compatibility between Zeta R1 and Haiku R1 is iffy now, because of the different libraries being used, but when R2 comes you say that they’ll be completely incompatible at the binary level. So then you have the problem with developers who only develop for Zeta. How will Haiku run Zeta-only programs? It will take a while for the advantages of Haiku over Zeta (opensource and free) to make Haiku more popular than Zeta, and until then, developers might only make programs for Zeta. And if more programs are available for Zeta than Haiku, then people might be drawn to Zeta and away from Haiku, and then slow Haiku’s adoption rate.
So do we just hope that commercial, closed source developers will compile for Haiku as well as Zeta? Or is there a way to provide interfaces in Haiku to allow Zeta programs to run natively? If there is, could this interfacing be extended to allow, say, Macintel and Windows programs to run too?
–Walter Huf–

C programs probably won’t have problems. Anything in C++ won’t be able to have binary compatibility with R1. When R2 is released, it will be generated with a 4.x GCC compiler. There have been significant changes in how GCC generates code for C++. The changes result in better performance, but they also break binary compatibility.

How much compatibility Zeta has with Haiku in a large way depends on YellowTab. The plans for R2 involve some major technologies that I’m not sure if YT has the resources or time for. It is also much easier for them to be compatible with Haiku than the other way around.

There are also some significant differences in how to approach problems, and this comes from the fact that they are a real-world company which requires real money to run. Haiku is an open source group of volunteers, so money doesn’t really have much play in the equation in the sense that nothing comes to a screeching halt if Haiku doesn’t pay anyone.

There are significant things that Zeta is doing in the APIs which will likely happen in R2 and some things that won’t. One of the big things that I’m seeing in Zeta-only apps is localization. That is sort of already under way in the OpenTracker project.

IMO Linux took a while to be accepted as more than just a bunch of code jockeys’ hobby because it is hard for Joe User to do anything with it. Usability is a hallmark trait of BeOS and Haiku which it inherited from MacOS (along with a healthy dose of common sense). Because Haiku is free and (once stable) easy to use, adoption will not be an issue. It won’t be immediate, but it will happen. The licensing of the source code is very commercial-friendly, unlike Linux, so someone like NVidia could build binary drivers with full 3D hardware acceleration and have no controversy about it.

Berd Korz and company have their own plans and we have ours. I know the big thing with Haiku is doing things the Right Way, which many businesses just can’t afford to do. YellowTab has been very good in raising BeOS awareness, though.

I can’t say for sure how much compatibility there will be between Haiku and Zeta. Quite a bit of it depends on them - they’ve got access to the sources to both their code and ours. I guess only time will tell