FreeLists / openbeos / [openbeos] Re: binary middle ground

["Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>]

I think that what you wrote below is a worst case scenario, but it could well
be true. 

Honestly, I think that source compatability is phase 1. Let's get there, keeping
an eye on binary compatability. At that point, we can really make a decision.
Late binding is your friend. :-)

I did not realize that the message was being posted to the list and (of all 
people)
*I* apologize for being off topic. 

Since I am posting here, though, I just wanted to crow a little - 

******* 100 ******** people on this mailing list! WOOOHOOOOOO!!!!
Think that might be enough people to get this done? I do! :-)
Lets pound through this and show the world what the BeOS community can do when 
it puts its mind to it! :-)


>Yes, but is this testing matrix worth the burdens necessary to create 
>it? If binary compatibility turns into a monstrous effort, then the 
>benefits of having it become extremely questionable. I worry about its 
>effect on the project timetables and developer morale. You don't want 
>version 1.0 pushed back by another 3 to 4 years. You don't want 
>programmers dropping off the list because they are tired of spending 
>month after month tearing their hairs out for little discernable 
>progress.
>
>Originally I supported the notion of binary compatibility for the 
>obvious reasons. Perhaps it was naive on my part, but I basically 
>assumed that Be's published API told us pretty all we needed to know 
>about the system. It didn't matter if the algorithms and data 
>structures we used to implement the API matched the original code or 
>not (indeed, it's almost certain they would be different), just so long 
>as equivalent functionality was met.
>
>But Eugenia's post on OSNews about her discussions with Be engineers 
>spooked me considerably. I have no reason to doubt that she's telling 
>the truth. If the internals of the kernel and libraries are riddled 
>with undocumented stuff, we have a task on our hands of monumental 
>proportions.
>
>Consider what the developers have to deal with. For example, we have to 
>implement function 'do_skippy'. Its interface and functionality is well 
>documented. No problem -- you implement and test to the spec. Now we 
>come across undocumented routine 'do_ufef_a'. What the hell does this 
>routine do? Eek, bring in the disassembler. Hmm, it seems to be doing 
>X, Y, and Z. Implement this... test... crash. Oh, well there must be 
>more to it than that. Oh, and there's another routine 'do_ufef_b'.  Is 
>it related? Does it share functionality, or is one of them an obsolete 
>routine that was never removed. Perhaps they rely on each other and 
>share a data buffer. If so, we better figure out the size and format of 
>the buffer exactly. We might re-implement the functionality of these 
>two routines exactly, but if we fail to properly set the data buffer 
>(wrong offsets, slightly different data or misaligned data...) then the 
>routines still crash and we're not sure what exactly we are doing 
>wrong. Keep hacking away at it.. weeks pass... months pass...
>
>This might be an exaggerated example. Maybe things won't be so bad. But 
>it doesn't look unreasonable to me. Multiply this scenario by the 
>number of undocumented routines we encounter and... well, you get the 
>picture.
>
>I like the idea of the testing  matrix. But is it sacrosanct? It is 
>more important than anything else? Perhaps we can do just as well with 
>another testing method (no, I don't have one right now, but I'll think 
>about it). 
>
>Of course, ditching binary compatibility also affects being able to run 
>old apps. But I do have an new idea in this regards. I'll send another 
>mail describing it as soon as I've gotten it all worked out.
>
>
>>
>>Binary compatability is good for the end users. It allows them to use 
>tons of apps that
>>are no longer being developed. It is good for us (as developers) 
>because we can test. 
>
>
>