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