[openbeos] Re: binary middle ground

There were a lot of responses, and I'm sure a bunch I haven't read yet 
(still catching up), so hopefully I'm not saying something totally 
redundant.

Having said that, I would like to suggest what I think is the most 
viable route for us to take.  First, let us assume that all apps use 
only the public APIs.  I think this is fairly reasonable since any app 
utilizing private APIs was already in danger of being broken if the next 
release of BeOS changed or removed the private API.  Working from this 
premise, we have only to insure that we reproduce the public APIs 
faithfully.  To wit:

- Class names and inheritance hierarchies must be the same
- Public and protected function signatures must be the same
- The vtable layout must be the same
- The data size of classes must be the same

These requirements are actually not as restrictive as they might seem.  
We can declare any number of private non-virtual functions we might need 
and completely omit those which do not suit our implementation -- these 
do not affect the vtable layout, the public interface or the class size. 
 If our implementation of a class has less data, we simply pad the 
object.  If we need more, we convert four bytes of the class data into a 
pointer to a struct holding our additional data.  If we stick to this, 
all sanely written apps *should* run out of the box.

Now, the first objection I can see someone making is that this 
compromises our "drop-in component" strategy, and to an extent this is 
true -- but I don't think we're going to reasonably be able to just 
replace the app_server, for example, and have it work with the original 
libbe.so anyway.  Decoding the interactions will be too difficult and 
time-consuming to be worth the effort, especially since these are 
behind-the-scenes interactions which apps and non-dependent parts of the 
system shouldn't care about.  What we *can* do, however, is identify 
what parts of the system are dependent on each other in a way that would 
be difficult (or even nearly impossible) to reimplement.  Then we 
consider those interdependent systems as single entities for drop-in 
replacement.

At any rate, this is the approach the interface kit team is 
contemplating.  We'll be working on the interface kit, the app kit and 
app_server (plus a couple of other little, dependent things) as 
sub-systems within a larger system that we'll be looking to drop-in.

Oh, and quickly, with regards to the "patched compatibility" solution, I 
don't see any real difference between this approach and the fully binary 
compatible solution -- either way, you're presenting the same function 
signatures and providing the same functionality (which we have to do no 
matter what solution finally gets implemented).  The only difference I 
see is that in the "patched" solution, the original function is a stub 
which calls another function to do the actual work.  Why not just have 
the functionality right there?  Delegating isn't going to gain anything 
here, IMO.

e

>In light of the recent information and discussion concerning binary 
>compatibility, I thought I'd rehash the issues and propose a middle 
>ground.
>
>The original OpenBeOS Charter was drafted with both source and binary 
>compatibility in mind. Source compatibility is a no-brainer: if you 
>don't have that, you don't have BeOS but some other OS instead. That 
>may be a worthy project, but it's not what OpenBeOS is about, so that 
>issue is settled.

[much snipping happened here]

Data is not information, and information is not knowledge: knowledge is 
not understanding, and understanding is not wisdom.
        - Philip Adams

Other related posts: