Re: Re: [UnixOS2] libc

On Wed, Jun 18, 2003 at 07:48:49PM +0200, Andreas Buening wrote:
> Holger Veit wrote:
> 
> [snip]
> 
> > We only have to preserve compatibility in that we need some fseek() and
> > fseek_64() at all, not with binary compatibility with existing code
> > (this can still access the old EMX DLLs and will be happy).
> 
> I can understand why you'd like to break binary compatibility.

Sure? I am curious...

To be precise: there are several definitions of binary (in-)compatibility,
so it is important to negotiate what we are talking about.

One is the question of ELF vs. a.out.
Another is ordinals vs. named DLL entries.
A third is g++ 2.8.x vs. 2.95 vs. 3.x.
The fourth is about API compatibility, as above the example of whether
off_t is 32 bit or 64 bit.
A fifth is the question whether some EMX successor should preserve all
older entry points.

And there are probably more stumbling blocks in the way that make the
compatibility issue a minefield.

Each of the above has the potential to break something old. The real
question behind the "binary compatibility" killer argument is:

Do we really want an improvement of the free OS/2 libc (call it EMX or 
different)?

If the answer is yes, then we *must* break something in order to
build something better, faster,more powerful (whatever the design goal
is). This is the unavoidable price to pay.

If the answer is no...well, German proverb tells us the problem:
Wash my fur, but don't make it wet. It is impossible, and then there is
no use in any further discussion on the topic (which is almost as old 
as the whole UnixOS2 movement).

> However, I have a bad feeling about doing this. Some libraries
> do this sometimes and this leads to a set of incompatible
> binary files which can become quite nasty. I'd like to keep also
> binary compatibility.

So, I'll put up the clear question above again:

Do you want an improvement? YES or NO?

Holger