Re: Re: [UnixOS2] libc

Ilya Zakharevich <[email protected]> Fri, 20 Jun 2003 02:29:57 -0700
Newsgroups gmane.comp.ide.emx.devel
Message-ID <[email protected]>
On Thu, Jun 19, 2003 at 05:15:08PM +0200, Andreas Buening wrote:
> 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.

This depends.  If the feature requires only a small amount of code, we
can just "duplicate" the code, and re#define the function to different
name.

Then a recompile of your application gives you a better mousetrap.
[Redefinition is needed since some of the libraries which use the old
mousetrap come as static libraries; with just changing an ordinal they
need a recompile too.]

But I do not see why new functions should come into the picture at
all.  The situation is simple:

  a) EMX needs to be *fixed*; it has many problems, and most of these
     problems are quite easy to fix.

     [Actually, IMO fixing these problems is *much* less
      time-consuming than participation in endless arguments whether
      one wants to fix these problems.  This is why I insist that EMX
      needs a new maintainer.]

  b) There is no need to *extend* EMX/EMXCRTM other than features
     *allowing* extension of EMX by third-parties software - and
     support for new builtins of new gcc's.

     [It would be very nice if these pieces were merged into as few
     DLLs as possible.  But this is an *eventual* target; one can add
     a wait period to avoid the scenario you mention - and merge
     things into CRT DLL after the wait expires.]

Hope this helps,
Ilya