[openbeos] Re: binary middle ground
- From: "Erik Jakowatz" <erik@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 10 Sep 2001 20:05:31 -0700
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:
