[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:

The thing that disturbs me somewhat is that other (Be published) apps might 
use unpublished APIs. :-/ That could force us to bundle certain kits together.
The issue with BONE and the printing kit is a good example.

>- 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

Public data has to be exactly the same. Private data, though, doesn't.

>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: