[openbeos] binary middle ground
- From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
- To: "OpenBeOS list server" <openbeos@xxxxxxxxxxxxx>
- Date: Thu, 30 Aug 2001 15:22:20 CDT
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.
Complete binary compatibility is a fantastic feature because it means
all the thousands of existing BeOS R5 apps can be run in OpenBeOS
immediately with no further effort required. It also allows for the
OpenBeOS developers to test their new replacement kits "piecemeal" by
inserting them into a working R5 system and testing against that. These
were compelling enough reason to put them into the Charter.
However, a few days ago, Eugenia posted an item on OSNews that put a
damper on this ideal. Having discussed OpenBeOS with several Be
engineers, she came to the conclusion that binary compatibility just
wasn't possible. I took this story very seriously and gave it a lot of
thought. It could be a case of developers being defensive and
exhibiting NIH (not invented here) mentality. But I think it is much
more likely that the comments were based on real technical facts --
that the BeOS internals are a little ugly and have too many
undocumented parts that would be extremely difficult to recreate by
outsiders.
Too me, this is new information. This is something that I didn't know
when drafting the original Charter. It is serious enough to warrant a
re-think about the basic goals of OpenBeOS. Several people posted
comments on this list, mostly in support of ditching binary
compatibility. After all, you don't want to waste valuable man-hours
(man-years?) trying to replicate specific implementations and even bugs
which are likely to be replaced in futher versions anyway. And yet,
ditching binary compatibility poses problems too -- mainly the prospect
of creating hundreds of orphaned R5 apps that aren't runable in
OpenBeOS.
Zenja Solaja had a suggestion that seems pretty reasonable. He remarks
that binary compatibility can always be achieved with a little reverse-
engineering. By dissassembling the R5 binaries and tracing down all the
calls, we can stub these calls in the OpenBeOS binaries. Now, in
actuality, this isn't complete binary compatibility because we may not
be able to patch in equivalent functionality. But we can at least
assure that the app doesn't crash from trying to make an invalid
library call. Assuming this can be done (and I don't see why it
couldn't), this gives us a middle ground to work with.
So lets sum up the 3 possible routes:
a) Source compatibility only
This is clean, much simpler, and ultimately more elegant. It carries
the burden of recompiling every R5 app that you would want to use in
OpenBeOS, which is troublesome.
b) Source and full binary compatibility
This is nirvana. Everything works perfectly out of the box. It also is
probably not feasible in a realistic time frame. Ultimately, I don't
think this is a practical route.
c) Source and patched binary compatibility
This is Zenja's middle ground. Old R5 apps should be executable, but
they may not perform as intended. They may still exhibited unexpected
crashes (but hey, programs do that anway, he adds sarcastically), but
they may also work well enough that people could still use them until a
newer or replacement app is available. This method also has the
advantage that you don't have to worry much about the binary issue in
the beginning -- you just write the replacement modules to the R5 API,
and then, at the end, do some reverse engineering to patch in the
needed stubs. This, too me, is clearly the path to shoot for.
Let me give an example of how these options work with a somewhat
inaccurate analogy:
Suppose you are developing a program that links to the "flub" libray.
You are looking at the following piece of code:
n = flub_dub ();
You need to replace 'flub_dub' but don't have the sources to the flub
library.
Solution 1: You change the function name and implement your own
version...
n = my_flub_dub ();
This is ditching source compatibility, and that is out of the question.
Solution 2: reimplement exactly...
flub_dub ()
{
... better make sure this works exactly like the original
}
n = flub_dub ();
Guaranteeing exactly equivalent results is an exhausing process (if
even dobable)...
Solution 3: patch in a stub...
my_flub_dub ()
{
... get as close as you can, but don't worry too much...
}
flub_dub ()
{
return my_flub_dub();
}
This is the patched solution. It may not seem much better than Solution
2, but it doesn't require any of the other apps that call 'flub_dub' to
be recompiled. Of course, you may run into problems if the stubbed in
version leaves out some required functionality. You do the best that
you can.
The hope is that most R5 third party apps adhere to the public API --
these should run no problem.
Ok, this is a long message from hell. Any comments?
Other related posts:
