[openbeos] Re: binary middle ground
- From: revol@xxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 30 Aug 2001 22:56:46 +0200 (MEST)
> 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.
I won't bet on either answer here :)
> 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.
>
About binary compatibility in userland: the main problems are we are
sandwitched between the app level and other layers (like graphics accelerants,
and codecs), so we need to know do which extend we want to be compatible
(only apps ?).
Problems also come from the fact all is in C++. If we want to keep binary
compatibility, we will have to face the fragile base class problems and so.
On ther kernel side, since it's only C, I think it will be easier to achive
binary compatibility, since we just have to implement the system calls and use
the same structures, though of course we still have more than one side,
userland and drivers.
Others will argue we need to also comply wih timing issues. I will be very
happy if we have even only the Be port of bash running on our kernel, even if
it goes 10 times slower. At least that will tell we can do it.
> 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.
objcopy --help|grep weak
might help (see http://www.linux.com/develop/man/1/objcopy/ ),
not really sure how.
also we could create compatibility libs just like Be did for BONE.
>
> Ok, this is a long message from hell. Any comments?
See above :)
++
François.
Other related posts:
