Talk:MinGW

message: What is the proper pronounciation for MinGW?
Min-gee-double-u?
ming-double-u?
Em-in-gee-double-u?
Earnie Boyd (one of the project admins) pronounces it Min-gee-double-u if that helps ...
(see http://sourceforge.net/mailarchive/forum.php?thread_id=4363554&forum_id=5119
and 
http://sourceforge.net/mailarchive/forum.php?thread_id=4363555&forum_id=5119
for other thoughts).
lol. Not knowing the origin of the name when I was using it, I always pronounced it "ming-whuh" (rhyming it with "lingua"). — FREAK OF NURxTURE (TALK) 20:52, 28 October 2005 (UTC)
thread_title: Pronunciation

message: Are requirements for LIB.EXE and LINK.EXE availability specified in library development section still actual?
No way, I removed them. --62.177.70.220 09:50, 22 June 2006 (UTC)
thread_title:  LINK.EXE and LIB,EXE mingw requirements 

message: The stuff under "Distribution Notes" should probably be removed... it belongs in some readme file, not in an encyclopedia. 72.201.244.179 03:50, 24 January 2007 (UTC)
thread_title:  Remove Distribution Notes? 

message: Having read the article I don't remotely understand what either MinGW or MSYS are. Could someone please alter it to explain it more slowly and thoroughly. 86.136.8.54 10:18, 3 July 2007 (UTC)
replies: text: Err, yeah, it is a bit technical right now. The key thing is that it's a Windows-native port of the GNU build system, which lets people use GCC and other free software for developing on Windows. Chris Cunningham 11:56, 3 July 2007 (UTC)

text: Well, what is your frame of reference? Why did you come to this article, to start? Are you a programmer? A *nix user? Ham Pastrami (talk) 17:43, 11 February 2008 (UTC)
thread_title:  MinGW and MSYS 

message: Where do the Windows API header files come from ?
It is supplied with a set of API libraries as well, even more curious to know where these come from. Also they obviously don't infringe on Microsoft copyrights. 
62.31.160.103 22:53, 6 September 2007 (UTC)
replies: text: I'd be interested to know this as well. I'm not entirely certain that it doesn't infringe on copyrights. Short of reverse-engineering the entirety of Win32, I don't see how else they would have come up with the headers and libraries except by basing it on Microsoft's Platform SDK (or the contents of Visual Studio) and the binaries that ship with Windows. But Microsoft also provides some of this free of charge, and perhaps with authorized redistribution so it's not necessarily an infringing use. Ham Pastrami (talk) 07:00, 11 February 2008 (UTC)
replies: text: The devs claim that w32api package is made using publicly-available documentation (MSDN, articles, books) and some reverse-engineering, and they never based anything on MS Platform SDK, didn't even look at it. In fact, they have (at the moment of writing) very strict policies about including things into w32api package, claiming that since mingw has many users, it is their duty to protect them from potential legal threats, and since they have no money for lawyers, the best thing they can do is to make sure the code is not infringing. This level of cautiousness can be viewed by some people (i.e. me) as ridiculous. Especially in comparison with mingw-w64 project. L.R.N (talk) 18:01, 8 March 2013 (UTC)
thread_title:  Origin of the Windows API header files and libraries

message: Should the OS be listed as Windows or cross-platform? From what I know MinGW runs in GNU/Linux, and it's stated in the article that MinGW can be used to cross-compile. CHL (talk) 13:09, 4 May 2008 (UTC)
replies: text: From what I can see on the project page, MinGW's binaries are not provided in any form other than for Windows. Ham Pastrami (talk) 18:53, 4 May 2008 (UTC)
replies: text: Yes, but there are MinGW-based cross-compilers in several Linux distributions.TorLillqvist (talk) 07:36, 4 August 2009 (UTC)
replies: text: That information would apply mainly to users of those Linux distros, not to users of MinGW in general. For reasons of clarity, forks of open source software do not become additive to discussing the base topic. Additional functionality that gets added on by third parties is discussed separately, assuming it is noteworthy and verifiable. Ham Pastrami (talk) 02:18, 5 August 2009 (UTC)

text: The Windows headers MinGW provides can be used to cross-compile. The Unix binary for MinGW's compiler is, like, GCC. Chris Cunningham (not at work) - talk 21:21, 4 May 2008 (UTC)
replies: text:  Correct. MinGW has been using a normal, stock version of GCC for some years now (built from mainline GCC sources without any patches). It's the w32api package that is really made by them. And MSYS. L.R.N (talk) 18:01, 8 March 2013 (UTC)
thread_title:  OS 

message: Came across an issue recently with gcc / MinGW compiler not working right and it turned out it wasn't just me -- relevant linuxhelp.150m.com article (1) Fortunately, someone else figured out and successfully made a cross-compiling / porting toolchain (not sure if they of the specific architecture, but they seemed to be using x86 / ia32 / ia64 / amd64) and did their cross-compiling successfully by reverting to gcc 4.2.3 relevant linuxhelp.150m.com article (2) ... I just can't think of any useful comments to add to either the MinGW or GNU Compiler Collection article about the sad reality -- STABLE releases of such cross platform / portable / cross-dev tools can sometimes be very outdated (over 2 years) Kuzetsa (talk) 21:29, 16 June 2008 (UTC)
thread_title:  MinGW 4.3.0 is in preview for a good reason 

message: What are the similarities and differences between MSYS and the (Windows) GNU Core Utilities? Thanks.  —Preceding unsigned comment added by 193.26.4.35 (talk) 11:55, 27 February 2009 (UTC)
replies: text: GnuWin32 consists of GNU utilities that were natively ported to W32. The ports are, IMO, rather incomplete (the library that provides POSIX compatibility for GnuWin32 has lots of stubs in it), and thus might miss some functionality (one of the features that should be missing is the ability to consistently interpret *nix-style paths (the ones that start with '/') in the input and produce such paths in the output). Naturally, GnuWin32, to my knowledge, does not provide a shell (bash), or ports of any other program that relies heavily on non-portable POSIX functions, such as fork(). L.R.N (talk) 18:01, 8 March 2013 (UTC)
thread_title: GNU Core Utilities

message: From the article:
:This means that developers do not need a Windows installation with MSYS to compile software that will run on Windows without Cygwin.
But developers still need Windows to test their software, so does this have any notable benefits? --Damian Yerrick (talk | stalk) 14:52, 22 April 2009 (UTC)
replies: text: Of course it does. It's not like Linux developers frequently have ready access to all sorts of weird Unixes that gcc will let them target, but it's still a bonus to be able to release binaries for them. Chris Cunningham (not at work) - talk 15:22, 22 April 2009 (UTC)
replies: text: But why would a developer release a binary if he doesn't know that the binary even works? --Damian Yerrick (talk | stalk) 15:27, 22 April 2009 (UTC)
replies: text: The article doesn't say that. Developers can (and should) have separate testing environments anyhow. Ham Pastrami (talk) 02:13, 23 April 2009 (UTC)

text: Wine is an option for running tests. Also, cross-compiling is faster than using MinGW/MSYS+autotools (to the point that it might be faster to run a GNU/Linux guest system in a VirtualBox that runs on a host W32 system to cross-compile W32 binaries for use on that host system). L.R.N (talk) 18:01, 8 March 2013 (UTC)
thread_title:  "Do not need Windows"? 

message: I noticed the following toward the end of the article:
"Accordingly, this approach requires Win32 programs written with Cygwin to run on top of a copylefted compatibility library that must be distributed with the program, along with the program's source code."
Not that I'm taking sides in this eternal debate, but isn't the above angrily disputed?  I believe the FSF insists quite loudly that compiling non-GPL software with their tools and linking against their libraries is entirely permitted and that anyone who says otherwise is either a flaming idiot, or is deliberately trying to scare people away from using the GNU tools as part of some massive worldwide capitalist conspiracy.
Ya know, might wanna mention that. 146.6.201.233 (talk) 19:55, 7 May 2009 (UTC)
replies: text: You might wanna read GPL vs GPL linking exception vs LGPL. Also might be of interest that Cygwin's compatibility library is not GNU code, so it's not the FSF's place to decide the licensing terms for it. I'm thinking this is probably important to understanding the argument, or at least shows some attempt at understanding before calling other people idiots. Ham Pastrami (talk) 07:57, 8 May 2009 (UTC)
thread_title:  Copyleft and source code remarks 

message: I saw on the article that the MinGW FAQ leads to , although still valid, there isn't a "faq-what" anchor. The history link pointing to  isn't valid anymore, its now . Why was my edit reverted? 203.142.61.45 (talk) 03:31, 5 August 2009 (UTC)
replies: text: The link edits were reverted mistakenly, as I reverted back to an earlier edit. I re-added these fixes to the article. Ham Pastrami (talk) 01:55, 6 August 2009 (UTC)
thread_title:  FAQ and History Link 

message: I tried to take out some misleading information about MinGW and its relationship to Cygwin, but it was reverted. Oh well, I don't have time for any silly games. So I will just state what I think are the facts here, then.
The article needs to point out more clearly that MSYS is intended to be used when building software and not when running it, to avoid people getting the misguided impression that MinGW-compiled code would have access to some a POSIX-like environment (as far as external commands go). (Sure, you can bundle MSYS with your MinGW-compiled app, but that is not a normal thing to do, and you could do so as well with a MSVC-compiled app, it is not a property of MinGW.)
The article gives the misleading impression that MinGW and Cygwin are both intended for more or less the same purpose, to port software from POSIX. Sure, I agree that MinGW is often used when building software originally written for POSIX (or originally written to be cross-platform). But that is mostly just because people are familiar with gcc and its use, and it fits in in existing build infrastucture, configury, makefiles, libtool, etc, more easily. MinGW can as well be used to compile code written only for Windows. MinGW should be seen as an alternative to Microsoft's compiler, as the APIs it provides are the same, as it uses the same C library. This is very different from Cygwin.
MinGW can in no way be said to be a fork of Cygwin. It is MSYS that is a fork of Cygwin. Don't confuse the two. It is perfectly possible to use MinGW without using MSYS. Cygwin (and thus MSYS) is a POSIX-like operating system hosted on top of Windows. MinGW is the GNU compiler and binutils confugured to produce and handle Windows binaries, plus the headers and import libraries required for compilation of such.
TorLillqvist (talk) 06:34, 5 August 2009 (UTC)
replies: text: I understood it to mean that MinGW could be considered a fork of parts of Cygwin in the sense that it is a fork of gcc -mno-cygwin and the support libraries that it uses. --Damian Yerrick (talk | stalk) 19:46, 5 August 2009 (UTC)
replies: text: But were those (very minor) support libraries used by non-Cygwin MinGW-compiled code created as part of the Cygwin project? Or the import libraries and headers (w32api)? Some reference to clear historical evidence would be needed here. And anyway, the main part in Cygwin is the POSIX emulation, surely, which MinGW has nothing to do with. TorLillqvist (talk) 08:25, 6 August 2009 (UTC)

text: The problem is phrases like "should be seen". This is a qualitative judgment that requires reliable sources. If people tend to use it in a way that they "should" not, it is not Wikipedia's place to tell them they are wrong for doing it. See Damian's comments re: the "fork" of Cygwin. You can clarify this part if you wish, as long as you keep it factual (e.g. "this package was forked, this one wasn't", and not "MinGW should not be considered a fork of Cygwin"). Ham Pastrami (talk) 01:36, 6 August 2009 (UTC)
replies: text: OK, thanks for the clarification, that of course makes much sense. I need to be more careful with my language when/if edit the article any more. TorLillqvist (talk) 08:25, 6 August 2009 (UTC)
thread_title:  Misleading information and edit wars 

message: Does this discussion thread, or more specifically this reply, fix the "no sources to support significance of fork" issue? One of the MinGW developers also called mingw64 "an unsanctioned fork" in this discussion (expand the comments section).
Sorry, the reason for removal sounded vague to me. 203.142.61.45 (talk) 00:56, 14 August 2009 (UTC)
replies: text: Please have a look at WP:RS and WP:V to see what Wikipedia considers a "source". (And note also that MinGW itself is on shaky ground in this respect, so is not a good example to live up to.) Ham Pastrami (talk) 02:10, 14 August 2009 (UTC)

text: I see, so you ask for clarification, and when that clarification is given in no uncertain terms, which you fail to meet, you call the whole thing a farce and make threats about disrupting the article. There's a reason these policies exist, not the least of which are to guard the encyclopedia against unsubstantiated opinions and conflicts of interest. Just so you know, you're hardly the first person on Wikipedia to try this approach, though you would be the first to succeed. You're welcome to try making good on your threats; however, since we've already had this discussion and you've made your attitude and your intentions known, don't expect much warning in the level of response. Of course, you could also continue the discussion rationally. Your choice. Ham Pastrami (talk) 17:03, 14 August 2009 (UTC)

text: If no clarification was required, then why did you ask for one? Now you're just contradicting yourself. You're the one who is completely ignorant of Wikipedia's processes and should have known better than to throw a tantrum and spew threats and insults. And somehow you manage the nerve to call others ignorant and hateful? Here's another expression you should add to your repertoire: self-righteousness. You seem to be under the impression that MinGW has anything to do with the page, or that I have anything to do with MinGW. My association is with Wikipedia, and so should yours be when you are editing. If you don't understand why that is, that's one of the reasons your edits get reverted. Don't let the door hit you. Ham Pastrami (talk) 05:22, 15 August 2009 (UTC)
thread_title:  mingw64 fork 

message: It seems that the domain mingw.org has expired and was not renewed. Thus the "homepage" link leads to a parked domain.
The project is alive and well. If you want to see the original server, use 74.63.13.247 for 'mingw.org' in your hosts file.
(Feel free to remove this section once the domain issue is settled) Tzafrir (talk) 16:32, 31 January 2010 (UTC)
replies: text: I removed the assertion that the domain was hijacked because no citation to a reliable source was provided. -- Schapel (talk) 15:49, 2 February 2010 (UTC)
thread_title:  Domain Expired (obsolete) 

message: It's an incredible project that works well for the future and this old one is at best mildly abandoned.  —Preceding unsigned comment added by 94.69.89.109 (talk) 08:52, 22 February 2010 (UTC)
replies: text: I personally have no opinion about having a second article, however, I do think the MinGW-w64 section should be given its own infobox. Before I add it myself, I would like to hear some comments. X-Fi6 (talk) 03:41, 17 July 2013 (UTC)
replies: text: Infobox added Helios crucible (talk) 06:33, 17 December 2014 (UTC)
thread_title:  Mingw-w64 will need its own article 

message: Current page shows "Stable release 	0.6.0 - beta". While this version number is indeed that of mingw-get.
Suggest to use "mingwrt-4.0.0-1, w32api-4.0.0-1, gcc 4.7.2".  — Preceding unsigned comment added by 114.93.27.30 (talk) 14:52, 7 April 2015 (UTC)
thread_title:  Version number? 

message: The MS Visual C RunTime Library is not the Windows API (which you can easily find described on the MS web sites): it is a MS implementation of parts of the POSIX/standard C API (POSIX defers to the Standard C Library for that part of the POSIX definition). Note: calls to the standard c library are not direct calls to the Windows API.
It's a common mistake for people coming from the Open Source side, because (as noted above), the standard C library /is/ the POSIX API (and always has been: unix exposed the system API as the unix programing environment).
It's sometimes a problem for programmers because (1) Using the C library as a wrapper around the native Windows API has performance implications, and (2) It's often confusing for programmers from other languages to read some behaviour described as "windows does this", when the behaviour is actually that of the MS c library, and is not implemented by the native Windows API (as documented by MS) at all.  — Preceding unsigned comment added by 203.206.162.148 (talk) 00:46, 10 November 2016 (UTC)
thread_title:  "MinGW links by default to the Windows OS component library MSVCRT, " 

message: Almost all use and development activity has shifted from this to Mingw-w64. While development of MinGW hasn't been abandoned completely, it is down to only one or two people, who are semi-active contributors at best. I feel like that this is one of those facts which just about everybody (in the relevant field) knows to be true, but unfortunately it is one of those truths which is rather difficult to demonstrate on the basis of reliable sources. SomethingForDeletion (talk) 03:52, 4 February 2023 (UTC)
thread_title:  Semi-moribund project