[openbeos] binary compatibility
- From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 26 Aug 2001 20:40:27 CDT
Here's a snippet by Eugenia from OSNews:
------------------------------------------------------------------
Our Take: I am sorry if I sound negative, but after discussing details
about the Open BeOS project with several ex and Be engineers the last
few days, they all came to (an easy for them) conclusion that this
project is going nowhere. Exactly because there are shortcomings in the
BeOS design, and because not all bugs or features of BeOS are known
from outsiders, it will be impossible to replicate the technology
without having the original BeOS source code. But what the team CAN do,
is to aim for source compatibility, not binary. While the threading,
bugs(!), locking and other details will behave differently between the
BeOS and OpenBeOS, it is already times easier to port BeOS applications
to OpenBeOS than trying to run them unmodified. This way, if the team
become really dedicated, we may see some good progress in less than a
year, othewise it will take years to come even into an alpha state
------------------------------------------------------------------
What do you think about this?
She may be right. At least as far as what is worth aiming for. I mean,
technically, you can't say that its *impossible* to implement binary
compatibility -- nothing's impossible in programming given enough time
and resources -- but it might well not be worth it. Besides, what
progammer wants to bust his ass month after month carefully trying to
recreate some else's bugs?!
Binary compatibility is a nice concept because it means instant access
to the thousands of apps written for the BeOS. But source compatibility
might be good enough. You have to convince hundreds of developers
(especially ones who haven't published their source) to recompile, but,
if OpenBeOS is a success, I don't think this will be too hard.
In a way, source compatibility is a better goal in the sense that it
lets you implement things in whatever way works best. The programming
API is the same, but the underlying code is as slick as you are capable
of making it.
Still, it's a deviation from the original charter. Should we re-think
this?
Other related posts:
