This chance is already away because the break was after the release of alpha 4. Yes many apps run on haiku but other lost. A beos r5 rebuild was already done at this state of the system. Then we get the package management.
The newsest break will be the 64 bit version, because so many old beos apps does not available with source or are not open source.
I hope to get the same way for haiku like on windows, so we can use 32bit apps on 64bit Systems.
Because of this we need a official release of haiku to have a haiku version without api ans binary breaks. And all new (64bit also) should be part of the nightly dev builds to develop and testing.
If people want to use the older, supported, apps on haiku who can use the first release and for the future we have a newer Version of haiku. Here all can break up to the next release.
The x64 version is not binary compatible, but except in very limited ways it is still restricted by the API and ABI compatibility of the 32 bit version, so it is of no use as an example of breakage. The fact is that the developers still take pains to ensure API and ABI compatibility with BeOS r5. In some rare cases I think API changes are made, but they are arranged very carefully to not break the ABI.
Playing devil’s advocate, to maintain BeOS ABI compatibility, key parts (the majority?) of the OS must be able to be compiled with GCC 2.95. This means no C++11/14/17 code in these parts of the OS. That’s a bit of a limitation for potential contributors to the OS, especially if they happen to use C++11/14(/17) at work, for example, and are quite used to AAA, the smart pointers, lambda functions etc. It can be a bit ‘weird’ to have to remember not to use these features.
The problem is that generally, the API remains tied to 90s, I will give you some general examples:
Little to no use of C++ templates
No use of C++ exceptions
Missing various data structures (pairs, maps …)
No C++11
I think an improvement of the BeAPI at this point would be a complete redesign.
Since it’s now two decades, the problem isn’t breaking the current ABI. I think a future API will introduce a completely new ABI, that we can call BeAPI 2.0. So except abandoning gcc2 we aren’t really going to break compatibility. I will speak for the Media Kit, at this point there’s not much to do to update the API. What I plan to do is redesigning it with modernity in mind and eventually the old media_kit could run on top of the new API to ensure apps compatibility.
The real issue is that to create a true R2 API we have to gain the same momentum we had around alpha4 times.
Except that as @extrowerk said those are a mix of bugs and usage of undocumented API, I don’t understand what you are going to do with a 90s website editor. So let’s stop thinking we have to support those programs.
We need modern apps made for modern computing, not rusty pieces which except from nostalgic people aren’t going to be useful to anyone.
Actually, this is more or less the plan with that beta1 release. The idea is that we create a “stable” R1 branch starting with beta1. In this branch we only merge bugfixes. It may never reach R1, but stay in eternal beta. Not a problem.
Meanwhile, the master branch can be freed of this compatibility requirement and move forward. It may also never reach a stable state or take another 20 years to get there. But meanwhile we can have more R1 betas, and eventually we can pick some of the new things from master and create an R2 branch.
Right now we are trying to do everything in the same place and this just can’t work.
It is also what keeps Haiku from breaking apart. Among its developers, there are very different ideas of what a future Haiku should be. The R5 API (+ various additions where it obviously makes sense) is a common goal. Without it… things might diverge quickly.
Actually we have this happening already. We need acknowledge this what we have, and name properly what we have to avoid confusion and stagnation in ideology:
32 bit Haiku — R1 branch 64 bit Haiku — R2 branch
I think, this is smart choice. 64 bit Haiku not binary compatible with BeOS anyway, and 32 bit software goes out of scene also anyway. There no actual point to make modern 32 bit OS or vintage 64 bit OS, but if we will support vintage 32 bit OS and modern 64 bit OS this will make more sence.
For compatibility 64 bit Haiku with BeOS it is enough that BeOS code will compile on 64 bit Haiku with minimal changes. With time 32 bit Haiku code can be used to make some BeOS binary compatibility layer (or maybe Virtualbox for 64 bit Haiku and virtualbox drivers for BeOS is even better). 32 bit Haiku binary compatibiltiy layer for 64 bit Haiku not needed.
I thought the 32 vs 64 bit break was a good idea as well… which is why I made it official without any real power to do so
Currently the general plan is to have a 32-bit and 64-bit Haiku release at R1. Given our track record of 20 years between releases… i’m personally a bit afraid to send R1 out the door without a 64-bit modern-gcc version attached.
As for ABI compatibility, I’d like to see our “non-legacy” gcc version bumped once more shortly before R1… gcc 5.x is beginning to get a bit old. I think we should bump the “non-legacy” gcc as far as we can before R1 (gcc 7.1?) … we likely won’t get another opportunity to cleanly bump the version for quite some time.
I’m afraid that you are confusing the terminology a bit here. R2 means not being tied to code that must be built with gcc 2.95 and not being tied to the r5 API or ABI. The 64-bit version of Haiku shares almost all of its code with the 32-bit version, so it is essentially only free from having to actually be built with 2.95, it still has 2.95 compatible and BeOS r5 API compatible source code, and is still limited in changing code if it would break the 32-bit code ABI compatibility.
As explained by @Barrett, as well as not breaking the API or causing changes in the 32-bit ABI, this means the 64-bit version can’t use any new features of C++ from newer compilers, and thus the only real benefits are better code generation from new compilers and not having to carry around two sets of compilers and libs. Plus, I guess, basic 64-bit benefits like larger process address space.
I should add that in my first post, all I really meant is that I am looking forward to a time when we are not constrained by r5, I want beta 1 or r1 to be released and see what comes next! I didn’t mean to start this debate!
I think some folks are forgetting there are end-users out there not willing to give up on some of the legacy BeOS applications that work on the 32-bit version of Haiku with no worthy alternatives. In my case it’s SoundPlay and I have asked Marco if he plans to dust off the code and he won’t give a straight answer. So I’m currently firmly seated into the 32-bit camp and have yet to maintain an install for the 64-bit version of Haiku until native apps that measure up to the likes of apps much like SoundPlay for example make their way (to 64-bit).
I think breaking SoundPlay compatibility is a blocker for quite a few.
I forget if his reasoning for keeping it closed was due to proprietary licensed code or not. His answer has always been rather clouded, so one could assume an NDA is involved.
I wonder if it’d be possible make an offer to Marco and have the community buy the code and release an open version?
What you talking about? I don’t tink so that there will be 32 bit R2 Haiku, what is a point for that? To be able to run SoundPlayer in 2030 on 2005 mashine? In some museum? even that will be inaccurat!
Right now we must separate old from new, no point in mixing them, lets 32 bit stays for R1 and 64 bit lets fly to R2 right now. And you allways will can run Haiku 32 bit or even BeOS in virtual mashine, that how I see supports for virtual mashine is more important than running SoundPayer on R2.
You’re getting ahead of yourself. R1 hasn’t been released yet and I seriously doubt R2 will quickly follow behind it. I’m not even thinking about R2 at this point.
