delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/06/14/03:34:08

Date: Mon, 14 Jun 1999 10:31:19 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Nate Eldredge <nate AT cartsys DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Hello World and File size
In-Reply-To: <37642B63.71F64C68@cartsys.com>
Message-ID: <Pine.SUN.3.91.990614102938.21962M-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Sun, 13 Jun 1999, Nate Eldredge wrote:

> Judging from the model of Linux, I don't think that the scenario you've
> been suggesting (that developers would react to standard library bugs by
> distributing new DLLs, ref Message-ID
> <Pine DOT SUN DOT 3 DOT 91 DOT 990609113301 DOT 11862I-100000 AT is> of June 9) is likely.  A
> more reasonable way of handling this (and, in my experience, one often
> used) is to report the bug to the maintainers

That would require a totally different development model than the one
adopted by DJGPP.  I'm not sure how familiar you are with the Linux
development procedures; neither will I go into discussing here
something which I happen to know only by hearsay.  It will suffice to
say that the development of core Linux functionality is much more
centralized than ours (some say too centralized).

I'm arguing that given the DJGPP model, it is impossible to have any
real control on the versions of the standard libraries that get
distributed with development utilities.  We already have [counting...]
at least 6 different people maintaining important parts of the
development environment.  I'm now old enough to realize that in this
messy world it is impractical to hope that a bunch of volunteers could
coordinate themselves so well as to avoid possible library-level
conflicts.

> perhaps a bugfixed version will be released quickly

Thanks for the vote of confidence.  However, last time my poor self
tried to release a bugfixed version ``quickly'', it took 5 months, and
I'm still counting (v2.03 is the case in point).  Perhaps adoption of
the DLL approach needs better programmers, too ;-).  Any takers?

> application, and perhaps distribute a statically linked binary.  After
> all, just because DLLs are provided needn't mean one is required to use
> them.  Statically linked binaries can remain a perfectly reasonable
> format.

If DLLs aren't used in almost all cases, adopting them would be a
waste of effort that is better spent elsewhere in DJGPP.  Therefore,
falling back to statically linked programs should be something you
don't count as your option when you decide whether to switch to DLLs.

> This doesn't mean I'm suggesting that DJGPP switch to DLLs now; I think
> the implementation issues make it impractical and remove several of its
> other advantages.  But I don't think we should decide against this
> approach in advance.

I didn't decide anything.  I was just expressing my personal views;
caveat emptor.  As we well know, many DJGPP-related decisions were
made by default rather than by deed, because deeds need dedicated
individuals to carry them out.

Please also bear in mind that Linux and similar OSes benefit much more
from shared libraries than DJGPP can ever hope, since the OS itself is
also a user of the library.

Last, but not least, I would dare to suggest that most Linux users
have much more background and experience than many DJGPP users.  These
differences must be taken into account when making decisions.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019