[openbeos] Re: binary middle ground
- From: Zenja Solaja <solaja@xxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 11 Sep 2001 14:38:40 +1000
In case people haven't noticed, the BeBook gives clear indication as to how
to create a shared library (../Be Book/The Kernel Kit/ImageConcepts.html).
To summarise, exported functions are prepended with _IMPEXP_KITNAME, which
is what other applications/kits link to, so we should have correct
order/offset of the vtables if we dont modify the header files. In the
Class definitions, BeInc have been gracious enough to reveal their private
members and methods, and even left a few reserved members/methods, so Class
sizes are known and no guess work is necessary. As long as we keep the
original BeOS header files as our blueprint (order and layout), we should
have no problems with 3rd party binary compatibility. BeInc used these
files to compile the original kits/libraries, and so will we. As far as
hidden API's are concerned, these should be kit internal API's, not
referenced from other kits, hence they're not exported in the header files.
One of the teams working on the smaller kits (Screensaver, Input, Game or
Similar) should achieve binary compatibility soon if they're using
unmodified BeOS header files. They should hopefully end this debate once
and for all.
> -----Original Message-----
> From: Michael Phipps [SMTP:mphipps1@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, September 11, 2001 2:45 AM
> To: openbeos@xxxxxxxxxxxxx
> Subject: [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
> >
> >
> >
>
>
>
>
>
----------------------
CONFIDENTIALITY NOTICE
----------------------
This email is intended only to be read or used by the addressee.
The information contained in this e-mail message may be confidential
information. If you are not the intended recipient, any use, interference
with, distribution, disclosure or copying of this material is unauthorised
and prohibited. Confidentiality attached to this communication is not waived
or lost by reason of the mistaken delivery to you.
If you have received this message in error, please delete it and notify us
by return e-mail or telephone Aristocrat Technologies Australia Pty Limited
on +61 2 9413 6300.
Other related posts:
