Re: Re: [UnixOS2] libc

Holger Veit wrote:
> 
> 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.

Binary compatibility means for me you can replace a DLL and your
programs still work. This includes API compatibility and the
preservation of the ordinal numbers (if you've ever used them).
C++ is another story. We can't do anything about the fact that the
g++ people change name mangling with every release (and that's
the reason why C is used for the libc and why the libc is called
lib_C_).

[snip]

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

Yes.


> 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.

This is the point I'm not totally convinced of. I agree that you have
much more knowlegde of the emx and OS/2 internals than me and, most
likely, than most people on this list. I do not say we must not
do an incompatible change but I'm very sceptical about it.

Sometimes I get the impression (I'm not talking about you, I'm just
generally speaking) that some people are going through the world
wearing a huge axe and taking no care of compatibility problems other
people might have. Nobody ever needs this feature so let's kill it.
Switching arguments of function foo() or adding some members to
structure bar would perform much better so let's change it.
xyz is a much better solution to that problem so let's remove that
option. If people really need it they can easily modify their bla
files. Who cares? This solution is much more beautyful. And, if
in doubt, they recompile everything.
Result? A huge bunch of incompatible stuff.

If we have to introduce an incompatibility into emx then we may do
it only once and never(*) again. And if anybody thinks six months
or a year later that xyz could be solved better by foo or nobody
needs option bar then the answer must be: Keep compatibility!
Otherwise we'll just get a bunch of (more or less) useless libraries.


(*) Never in this sense means never within this computer age which
is equivalent to 10 years in real time. ;-)


[snip]


Bye,
Andreas