[openbeos] Re: binary middle ground
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 10 Sep 2001 11:44:58 -0400
>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:
