[openbeos] Re: binary compatibility

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: