[openbeos] Re: binary compatibility
- From: "Erik Jakowatz" <erik@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 27 Aug 2001 06:24:59 -0700
Eugenia may be right, binary compatibility might be shooting for the
moon. I still think it's do-able, and still think we should go for it.
If, in the course of our implementation, it turns out to be
impossible/unworkable, we can reevaluate then, checking in with the
larger community. Either way, applications which rely on bugs in the
system are going to have a difficult time; this has little, if any,
bearing on achieving binary compatibility. I'm not worried about this
issue; those sorts of applications are bound to have problems if Be/Palm
fixes the bugs. The same goes for apps relying on undocumented APIs,
except that binary compatibility will be lost for those apps as well.
Again, this could have happened anyway in the regular course of
upgrading the OS.
What worries me more is the impact of undocumented calls and IPC
protocols in attaining binary compatibility *within* the system -- it
may be that dropping in a replacement app_server (for example) is not
feasible in terms of working properly with the other servers. We can
minimize this by determining which servers rely on each other and
treating those servers as a distinct unit. For example, the Interface
Kit team is responsible for implementing the Interface Kit/App
Kit/app_server trio: rather than treat them separately, we will try to
treat them all as one unit (for replacement purposes) so that we don't
have to sweat the existing interactions between them. Perhaps some
uber-hacking will reveal the crucial information, and this won't be
necessary. Either way, if the public binary interface we present is the
same, we should be good to go as far as stand-alone apps are concerned.
Be did manage it themselves, after all, and I'm sure object dumping the
R4 servers and libraries would produce noticably different output from
object dumping R5.0.3.
The main thing is that we've hardly started. Let's not go removing
portions of the charter until we've invested enough research to fairly
say what can and cannot be done.
Thanks,
e
>I talked this with Marcus Overhagen the other day..
>i told him of my concerns about binary compatibility, and how i thought
>source compatibility
>was a better way to go, this way you can provide a new implementation
>bug-free (coff) but
>with BeApi's interface. Also this would speed the development alot..
>searching for bugs and
>implementing them is a nag :)
>
>Hugo Santos
>
>----- Original Message -----
>From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
>To: <openbeos@xxxxxxxxxxxxx>
>Sent: Monday, August 27, 2001 2:40 AM
>Subject: [openbeos] binary compatibility
>
>
>>
>> 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?
Data is not information, and information is not knowledge: knowledge is
not understanding, and understanding is not wisdom.
- Philip Adams
Other related posts:
