From: John P. <joh...@ho...> - 2002-07-27 02:33:13
|
Why do mingw32 users continue to use a runtime library dependent of MSVCRT.DLL? There is a project to totally replace MSVCRT.DLL. Here are the advantages of the Mingw32 Alternate C Runtime Library (no stable version released, just a unstable, incomplete version): - Easy to modify - Can be easily tweaked - Can be compiled without Microsoft Visual C++ - Open Source - Free to distribute, even without owning Microsoft Visual C++ or Microsoft Windows - Can be compiled with Wine (with both native platform gcc and with Mingw32 cross-compiler) - Will be 100% ISO C99 compliant when complete - Bugs cannot be easily fixed in the MSVCRT.DLL distribution (unless someone has a valid license of Microsoft Visual C++) - Will support both static and dynamic linking when complete, unlike other Mingw32 runtimes (MSVCRT.DLL can only be dynamically linked, but Microsoft Visual C++ also ships with two release static C Runtime Library called LIBC.LIB and LIBCMT.LIB) Developers, please contribute to the Mingw32 Alternate C Runtime Library found at http://mingwacr.sourceforge.net. If you are going to contribute, send email to jp...@us.... Cygwin developers: NOTE: The cygwin setup program should not be linked with MSVCRT.DLL or CRTDLL.DLL. It should also not be linked with the cygwin library. It needs to be linked with a static native Win32 C Runtime Library, such as what the Mingw32 Alternate C Runtime Library is going to be. If you are a developer wishing to contribute to the library, please do so. Please send email to jp...@us... if you are going to contribute. Developers should participate in the efforts, so that a Cygwin setup program can be written the way it should be without having to use a commercial Win32 compiler such as Microsoft Visual C++.NET. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
From: Steven E. <ste...@ya...> - 2002-07-27 02:48:16
|
Doesnt newlib do the same? --- John Platts <joh...@ho...> wrote: > Why do mingw32 users continue to use a runtime library dependent of > MSVCRT.DLL? > > There is a project to totally replace MSVCRT.DLL. Here are the advantages of > the Mingw32 Alternate C Runtime Library (no stable version released, just a > unstable, incomplete version): > - Easy to modify > - Can be easily tweaked > - Can be compiled without Microsoft Visual C++ > - Open Source > - Free to distribute, even without owning Microsoft Visual C++ or Microsoft > Windows > - Can be compiled with Wine (with both native platform gcc and with Mingw32 > cross-compiler) > - Will be 100% ISO C99 compliant when complete > - Bugs cannot be easily fixed in the MSVCRT.DLL distribution (unless someone > has a valid license of Microsoft Visual C++) > - Will support both static and dynamic linking when complete, unlike other > Mingw32 runtimes (MSVCRT.DLL can only be dynamically linked, but Microsoft > Visual C++ also ships with two release static C Runtime Library called > LIBC.LIB and LIBCMT.LIB) > > Developers, please contribute to the Mingw32 Alternate C Runtime Library > found at http://mingwacr.sourceforge.net. If you are going to contribute, > send email to jp...@us.... > > Cygwin developers: > NOTE: The cygwin setup program should not be linked with MSVCRT.DLL or > CRTDLL.DLL. It should also not be linked with the cygwin library. It needs > to be linked with a static native Win32 C Runtime Library, such as what the > Mingw32 Alternate C Runtime Library is going to be. If you are a developer > wishing to contribute to the library, please do so. Please send email to > jp...@us... if you are going to contribute. Developers > should participate in the efforts, so that a Cygwin setup program can be > written the way it should be without having to use a commercial Win32 > compiler such as Microsoft Visual C++.NET. > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com |
From: Robert C. <rob...@sy...> - 2002-07-27 03:08:23
|
On Sat, 2002-07-27 at 12:33, John Platts wrote: > Why do mingw32 users continue to use a runtime library dependent of=20 > MSVCRT.DLL? ... >=20 > Cygwin developers: > NOTE: The cygwin setup program should not be linked with MSVCRT.DLL or=20 > CRTDLL.DLL. It should also not be linked with the cygwin library. It need= s=20 > to be linked with a static native Win32 C Runtime Library, such as what t= he=20 > Mingw32 Alternate C Runtime Library is going to be. If you are a develope= r=20 > wishing to contribute to the library, please do so. Please send email to=20 > jp...@us... if you are going to contribute. Developers=20 > should participate in the efforts, so that a Cygwin setup program can be=20 > written the way it should be without having to use a commercial Win32=20 > compiler such as Microsoft Visual C++.NET. Hi, I'm the cygwin setup.exe maintainer. I don't use any microsoft development tools to build/release/test setup.exe. I think what you are attempting is interesting, and very similar to what cygwin1.dll is - a C runtime (well, cygwin is a posix API runtime including C runtime) for win32. However, I don't have time to help build YACL. Patches to link setup.exe with your mingw ACR will be considered like all other patches - I'm not particularly for or against linking into it. Before I release a version to the web site linked with such a library, the library (as a -devel package) would need to be part of the cygwin net distribution (as a matter of policy I only use tools available via the cygwin net distribution to build and distribute setup.exe). BTW: Your comment about a commercial win32 compiler being needed is 100% inaccurate. Good luck, and cheers. Rob |
From: Tor L. <tm...@ik...> - 2002-07-27 07:14:44
|
John Platts writes: > Why do mingw32 users continue to use a runtime library dependent of > MSVCRT.DLL? Why not? People use the proprietary vendor-supplied C library on Solaris, HP-UX, etc all the time, even if they use gcc as a compiler. --tml |
From: Joerg B. <jo...@sq...> - 2002-07-29 09:10:43
|
Hi! Tor Lillqvist wrote: > > John Platts writes: > > Why do mingw32 users continue to use a runtime library dependent of > > MSVCRT.DLL? > > Why not? People use the proprietary vendor-supplied C library on > Solaris, HP-UX, etc all the time, even if they use gcc as a compiler. Exactly. If MinGW were not using the Microsoft supplied libraries, I would probably not be permitted to use it in generating my library which becomes part of a commercial product. Be the reasons good or bad, many companies still will not allow distributing "Open Source" code. Use (and appraisal!) of such a tool is ok, but the resulting binary must not rely on anything but vendor-supplied stuff (OS + runtime libs + utilities). Especially with the multitude of "Windows" versions (from "95" to the several "2000"), it is essential to reduce the number of unknowns - with a non-MS runtime, SW distributors would get the blame for too many platform and version problems. (I just encountered different behaviour between NT and 2000 - I am glad there was no external lib involved, so I know the culprit is Microsoft and noone else.) Regards, Joerg Bruehe -- Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany (speaking only for himself) mailto: jo...@sq... |
From: Luke D. <cod...@ho...> - 2002-07-29 09:55:56
|
----- Original Message ----- From: "Joerg Bruehe" <jo...@sq...> To: <min...@li...> Cc: "John Platts" <joh...@ho...> Sent: Monday, July 29, 2002 5:10 PM Subject: Re: [Mingw-users] A Mingw32 runtime library independent of MSVCRT.DLL > Hi! > > Tor Lillqvist wrote: > > > > John Platts writes: > > > Why do mingw32 users continue to use a runtime library dependent of > > > MSVCRT.DLL? > > > > Why not? People use the proprietary vendor-supplied C library on > > Solaris, HP-UX, etc all the time, even if they use gcc as a compiler. > > Exactly. > > If MinGW were not using the Microsoft supplied libraries, > I would probably not be permitted to use it in generating > my library which becomes part of a commercial product. As its name implies, the Mingw Alternate C Runtime is an _alternative_ to MSVCRT.DLL, and would not replace it entirely (for the reasons that you give). > > Be the reasons good or bad, many companies still will not allow > distributing "Open Source" code. Use (and appraisal!) of such a > tool is ok, but the resulting binary must not rely on anything > but vendor-supplied stuff (OS + runtime libs + utilities). That assumes that the alternate runtime is a DLL, but there is no reason why you couldn't link it statically. At least developers using Mingw would have a choice between static and dynamic, like commercial compilers provide, and unlike the current Mingw runtime. Even if you use the runtime as a DLL, for most applications you could still just install a copy of the DLL in the same directory as your application (I know there are exceptions, but a static library should cover those cases). > > Especially with the multitude of "Windows" versions (from "95" > to the several "2000"), it is essential to reduce the number of > unknowns - with a non-MS runtime, SW distributors would get the > blame for too many platform and version problems. > (I just encountered different behaviour between NT and 2000 - > I am glad there was no external lib involved, so I know the culprit > is Microsoft and noone else.) > > Regards, > Joerg Bruehe > > -- > Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany > (speaking only for himself) > mailto: jo...@sq... I'm not involved with the alternate runtime project but I believe that many users would benefit from such a library. There is no need to discuss the bugs and other problems with MSVCRT because the advantages of an open source C runtime are reason enough to use it. However, I agree with Earnie that some earlier posts sound too much like advertisements to be considered relevant to this list. I also agree with several other posts that it would be far quicker and easier to use an existing library like newlib instead of starting from scratch. Luke Dunstan |
From: Joerg B. <jo...@sq...> - 2002-07-29 10:42:45
|
Hi! Luke Dunstan wrote: > > ----- Original Message ----- > From: "Joerg Bruehe" <jo...@sq...> > [...] > > > > Tor Lillqvist wrote: > > > > > > John Platts writes: > > > > Why do mingw32 users continue to use a runtime library dependent of > > > > MSVCRT.DLL? > > > > > > Why not? People use the proprietary vendor-supplied C library on > > > Solaris, HP-UX, etc all the time, even if they use gcc as a compiler. > > > > Exactly. > > > > If MinGW were not using the Microsoft supplied libraries, > > I would probably not be permitted to use it in generating > > my library which becomes part of a commercial product. > > As its name implies, the Mingw Alternate C Runtime is an _alternative_ to > MSVCRT.DLL, and would not replace it entirely (for the reasons that you > give). My very personal opinion: - There are MinGW users who _must_ use MS runtime for the reasons quoted (I am one of them), so this possibility is a requirement. - If others want to have and use alternatives, that is fine with me (as long as it does not break the above requirement). - If the number of alternatives becomes too large, it will become more and more difficult for newcomers to switch to MinGW. We have several "How do I start ...?" postings already - imagine how these would multiply by the alternative runtime libs. - The "best way" would probably be a strictly sequential approach: 1) MinGW installation and use starts based on MSVCRT. (For ease of install, to reduce the number of possible errors.) 2) People have a standard way to verify that setup. (Jumping from an instable point is no good.) 3) If that is successful, there are ways to switch to an alternate runtime (for those so inclined). As I am personally forced to use MSVCRT (and my MinGW use is for business only, not private), I am not the one to comment on the other points raised in this discussion. Regards, Joerg Bruehe -- Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany (speaking only for himself) mailto: jo...@sq... |
From: Steven E. <ste...@ya...> - 2002-07-29 13:33:07
|
> I'm not involved with the alternate runtime project but I believe that many > users would benefit from such a library. There is no need to discuss the > bugs and other problems with MSVCRT because the advantages of an open source > C runtime are reason enough to use it. However, I agree with Earnie that > some earlier posts sound too much like advertisements to be considered > relevant to this list. I also agree with several other posts that it would > be far quicker and easier to use an existing library like newlib instead of > starting from scratch. I would suggest that you guys take a look at the ReactOS MSVCRT,CRTDLL and psx subsystem. We are also reimplementing these C runtimes. Rather then have 2 or 3 small projects with only a few people working on them mabey you should join us to help pool developer time. I know that for our psx runtime newlib s being used as the base. CRT and MSVCRT are a clean implemention with ideas taken from newlib, cygwin and wines msvcrt. I have not read anything about your licensing so we might not be able to work together. ReactOS is GPL and always will be. Just a thought Steven __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com |
From: Oscar F. <of...@wa...> - 2002-07-29 16:25:57
|
Steven Edwards <ste...@ya...> writes: > I would suggest that you guys take a look at the ReactOS > MSVCRT,CRTDLL and psx subsystem. Guess that you need to "replicate" the functionality of those libraries, bugs and nuisances included, or risk serious compatibility problems. Having a "clean" C RTL is one of the motivations for doing a new implementation. Obviously, using your MSVCRT would not provide that. [snip] > I have not read anything about your licensing so we might not be > able to work together. ReactOS is GPL and always will be. AFAIK, MinGW born precisely for avoiding cygwin.dll and it's GPL virus... -- Oscar |
From: Luke D. <cod...@ho...> - 2002-07-31 01:51:11
|
----- Original Message ----- From: "Oscar Fuentes" <of...@wa...> To: <min...@li...>; <ste...@ya...> Sent: Tuesday, July 30, 2002 12:26 AM Subject: Re: [Mingw-users] A Mingw32 runtime library independent of MSVCRT.DLL > Steven Edwards <ste...@ya...> writes: > > > I would suggest that you guys take a look at the ReactOS > > MSVCRT,CRTDLL and psx subsystem. > > Guess that you need to "replicate" the functionality of those > libraries, bugs and nuisances included, or risk serious compatibility > problems. Having a "clean" C RTL is one of the motivations for doing a > new implementation. Obviously, using your MSVCRT would not provide > that. The ReactOS version of MSVCRT.DLL would probably need to exactly imitate the MS version, but perhaps Steven was suggesting that it could still be used as a basis for a new alternate C runtime. I believe the main point is to reuse code rather than reinventing it. > > [snip] > > > I have not read anything about your licensing so we might not be > > able to work together. ReactOS is GPL and always will be. > > AFAIK, MinGW born precisely for avoiding cygwin.dll and it's GPL > virus... > > -- > Oscar Even a GPL library would be useful to many users, but remember that Linux is GPL too so it may be possible to use a ReactOS C runtime in non-GPL code: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." So if ReactOS provided static libraries or the DLLs for users to download (including but not limited to MSVCRT), non-GPL applications could still link with these "major components of the OS" that are licensed under the GPL. Then again, I am far from an expert in these matters, and maybe this exception doesn't apply unless you are using the ReactOS C RTL with the ReactOS operating system itself (as opposed to MS Windows). Luke Dunstan |
From: Oscar F. <of...@wa...> - 2002-07-31 03:24:04
|
"Luke Dunstan" <cod...@ho...> writes: > > > I would suggest that you guys take a look at the ReactOS > > > MSVCRT,CRTDLL and psx subsystem. > > > > Guess that you need to "replicate" the functionality of those > > libraries, bugs and nuisances included, or risk serious compatibility > > problems. Having a "clean" C RTL is one of the motivations for doing a > > new implementation. Obviously, using your MSVCRT would not provide > > that. > > The ReactOS version of MSVCRT.DLL would probably need to exactly imitate the > MS version, but perhaps Steven was suggesting that it could still be used as > a basis for a new alternate C runtime. I believe the main point is to reuse > code rather than reinventing it. Yes, then the offer starts to make sense, but... > > > I have not read anything about your licensing so we might not be > > > able to work together. ReactOS is GPL and always will be. > > > > AFAIK, MinGW born precisely for avoiding cygwin.dll and it's GPL > > virus... > > Even a GPL library would be useful to many users, but remember that > Linux is GPL too so it may be possible to use a ReactOS C runtime in > non-GPL code: Linux is the OS. For we MinGW users, Windows is the OS and the ReactOS MSVCRT is not distributed with Windows. A different things applies to ReactOS users, of course. > "The source code for a work means the preferred form of the work for > making modifications to it. For an executable work, complete source > code means all the source code for all modules it contains, plus any > associated interface definition files, plus the scripts used to > control compilation and installation of the executable. However, as a > special exception, the source code distributed need not include > anything that is normally distributed (in either source or binary > form) with the major components (compiler, kernel, and so on) of the > operating system on which the executable runs, unless that component > itself accompanies the executable." I'm afraid that the above has not the meaning you interpreted. It talks about "distribution", not about the legal status of the code that uses those libraries. Please note that it talks about "the _source_ _code_ distributed ..." > So if ReactOS provided static libraries or the DLLs for users to download > (including but not limited to MSVCRT), non-GPL applications could still link > with these "major components of the OS" that are licensed under the > GPL. The problem, as said above, is that the ReactOS' MSVCRT is not a major component of Windows. You need to obtain it elsewhere. > Then again, I am far from an expert in these matters, and maybe this > exception doesn't apply unless you are using the ReactOS C RTL with the > ReactOS operating system itself (as opposed to MS Windows). Right. -- Oscar |
From: Steven E. <ste...@ya...> - 2002-07-31 15:06:08
|
I would guess only about 10 or so have messed with our MSVCRT. If you wanted to fork it and get permission to use the code + take parts of WINE that are LGPL you might be able to get the ReactOS dev team to go LGPL. Just a thought but then again we could all move to newlib and be done with it. > > The ReactOS version of MSVCRT.DLL would probably need to exactly imitate the > > MS version, but perhaps Steven was suggesting that it could still be used as > > a basis for a new alternate C runtime. I believe the main point is to reuse > > code rather than reinventing it. > > Yes, then the offer starts to make sense, but... > __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com |
From: Christopher F. <cg...@re...> - 2002-08-01 15:38:02
|
On Wed, Jul 31, 2002 at 08:05:38AM -0700, Steven Edwards wrote: >I would guess only about 10 or so have messed with our MSVCRT. If you >wanted to fork it and get permission to use the code + take parts of >WINE that are LGPL you might be able to get the ReactOS dev team to go >LGPL. Just a thought but then again we could all move to newlib and be >done with it. newlib does not have any understanding of the Windows API, AFAIK. cgf |
From: Kees Z. <kz...@us...> - 2002-07-27 08:06:35
|
It seems any runtime library running on Win32, Msvcrt.dll or a new one, would ultimately have to depend on Win32 kernel functions, such as those in kernel32.dll. These kernel functions are also copyrighted and difficult to change, if at all. So the development of a new runtime library is only needed if the existing library (msvcrt.dll) does a bad job in translating to the kernel functions or if its functions can be substantially improved. Whether this is the case is, of course, a matter of your own judgment. Personally, I do not think Msvcrt.dll is that bad. It is not a POSIX library, but if POSIX is needed, one had better turn to Cygwin. And when a new runtime library is yet to be developed, I think it should be an adaptation of either Newlib or Glibc. I am not sure whether Newlib and Glibc are developed in parallel or whether one is derived from the other. In any case, Glibc has been setup to compile on different systems, and its default version certainly can be compiled on Win32; the change to a true Win32 version of Glibc can then be made gradually by adding Win32 system dependencies. Kees Zeelenberg ----- Oorspronkelijk bericht ----- Van: "John Platts" <joh...@ho...> Aan: <min...@li...>; <cy...@cy...> Verzonden: zaterdag 27 juli 2002 4:33 Onderwerp: [Mingw-users] A Mingw32 runtime library independent of MSVCRT.DLL > Why do mingw32 users continue to use a runtime library dependent of > MSVCRT.DLL? > > There is a project to totally replace MSVCRT.DLL. Here are the advantages of > the Mingw32 Alternate C Runtime Library (no stable version released, just a > unstable, incomplete version): > - Easy to modify > - Can be easily tweaked > - Can be compiled without Microsoft Visual C++ > - Open Source > - Free to distribute, even without owning Microsoft Visual C++ or Microsoft > Windows > - Can be compiled with Wine (with both native platform gcc and with Mingw32 > cross-compiler) > - Will be 100% ISO C99 compliant when complete > - Bugs cannot be easily fixed in the MSVCRT.DLL distribution (unless someone > has a valid license of Microsoft Visual C++) > - Will support both static and dynamic linking when complete, unlike other > Mingw32 runtimes (MSVCRT.DLL can only be dynamically linked, but Microsoft > Visual C++ also ships with two release static C Runtime Library called > LIBC.LIB and LIBCMT.LIB) > > Developers, please contribute to the Mingw32 Alternate C Runtime Library > found at http://mingwacr.sourceforge.net. If you are going to contribute, > send email to jp...@us.... > > Cygwin developers: > NOTE: The cygwin setup program should not be linked with MSVCRT.DLL or > CRTDLL.DLL. It should also not be linked with the cygwin library. It needs > to be linked with a static native Win32 C Runtime Library, such as what the > Mingw32 Alternate C Runtime Library is going to be. If you are a developer > wishing to contribute to the library, please do so. Please send email to > jp...@us... if you are going to contribute. Developers > should participate in the efforts, so that a Cygwin setup program can be > written the way it should be without having to use a commercial Win32 > compiler such as Microsoft Visual C++.NET. > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Robert C. <rbc...@cy...> - 2002-07-27 08:21:12
|
.. > In any case, Glibc has been setup to compile on different systems, and it= s > default version certainly can be compiled on Win32; the change to a true > Win32 version of Glibc can then be made gradually by adding Win32 system > dependencies. Some very good points there. Another one to consider is that Reactos (http://www.reactos.com) has already built an opensource C runtime that is a drop in replacement for MSVCRT.=20 Rob |
From: Nicholas W. <nw...@ya...> - 2002-07-27 14:05:26
|
--- Kees Zeelenberg <kz...@us...> wrote: > In any case, Glibc has been setup to compile on different systems, > and its > default version certainly can be compiled on Win32; the change to a > true > Win32 version of Glibc can then be made gradually by adding Win32 > system > dependencies. Since when? The last time I heard, glibc would only compile on linux and hurd, nothing else. A quick check of the glibc ports page confirms this. Cheers, Nicholas __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com |
From: Kees Z. <kz...@us...> - 2002-07-27 14:18:12
|
Some time ago I did compile a static library, I believe it was 2.2.3. It just needed some standard headers and some win32 stubs. Indeed, the whole setup of glibc is that it uses stubs whenever a system dependent function is not provided, and so it should compile relatively easily on new systems. I never got to testing whether it was anything that could be fruitfully used, though. Kees Zeelenberg ----- Oorspronkelijk bericht ----- Van: "Nicholas Wourms" <nw...@ya...> Aan: "Kees Zeelenberg" <kz...@us...>; "John Platts" <joh...@ho...>; <min...@li...>; <cy...@cy...> Verzonden: zaterdag 27 juli 2002 16:05 Onderwerp: Re: [Mingw-users] A Mingw32 runtime library independent of MSVCRT.DLL > > --- Kees Zeelenberg <kz...@us...> wrote: > > In any case, Glibc has been setup to compile on different systems, > > and its > > default version certainly can be compiled on Win32; the change to a > > true > > Win32 version of Glibc can then be made gradually by adding Win32 > > system > > dependencies. > > Since when? The last time I heard, glibc would only compile on linux > and hurd, nothing else. A quick check of the glibc ports page > confirms this. > > Cheers, > Nicholas > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Earnie B. <ear...@ya...> - 2002-07-28 03:05:00
|
John Platts wrote: > > Why do mingw32 users continue to use a runtime library dependent of > MSVCRT.DLL? > Because that's what MinGW is. John, you're in danger of my considering your posts about this library SPAM and I'll have to take evasive action. Earnie List Administrator |