Date: Mon, 14 Jun 1999 10:31:19 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Nate Eldredge cc: djgpp AT delorie DOT com Subject: Re: Hello World and File size In-Reply-To: <37642B63.71F64C68@cartsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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 > 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.