Talk:MinGW

Pronunciation

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 NUR_xTURE (TALK) 20:52, 28 October 2005 (UTC)

It should be pronounced 'minj double-yoo' - as in 'minge'. ;) Pulseczar 16:41, 29 October 2007 (UTC)

LINK.EXE and LIB,EXE mingw requirements

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)

Linux-like?

At the risk of sounding too much like RMS, I'm going to be semantic here. Shouldn't it be a GNU-like enviornment, versus a Linux-like one? After all, the G in MinGW stands for GNU. Linux is just a kernel, and as MinGW32 runs on a Windows system, it uses the Windows kernel. It has virtually no link to Linux other than Linux usually using a GNU environment. Mpeg4codec 18:35, 7 January 2006 (UTC)

The only mention of "Linux-like" I see in the article is with reference to Cygwin, not to MinGW.  :) — Haeleth Talk 01:15, 8 January 2006 (UTC)

Must have gotten my thoughts jumbled. In any case, I believe much of my above argument still applies. Cygwin strives to emulate the user space and library functions, which consist mostly of GNU software (userland, glibc, etc.). Considering that at least one other kernel that I know of has been combined with the GNU utilities (GNU/Hurd), I'd say linking GNU strictly to Linux is not entirely appropriate. In conclusion, I believe the article should be changed to note that Cygwin provides a GNU environment, possibly adding that it is in many ways similar to the environment found on most Linux computers.

To ramble on a bit further, wouldn't calling it a true POSIX environment be even more accurate? In the end, I suppose it's all just a matter of semantics.. Mpeg4codec 05:02, 10 January 2006 (UTC)

I happen to be of the same opinion, and wouldn't argue if someone were to change the wording here. The reason I used "Linux-like" here (at least, I think that was my doing) is that that's the wording the Cygwin website uses now. Probably because more people know what Linux is like than know about POSIX.  :/

(Incidentally, Cygwin's libc is newlibc, not glibc. Which actually makes it less like Linux, but...) — Haeleth Talk 16:50, 11 January 2006 (UTC)

I think my edit accomplishes both our goals :). Mpeg4codec 14:40, 12 January 2006 (UTC)

Remove Distribution Notes?

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)

MinGW and MSYS

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)

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)

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)

Origin of the Windows API header files and libraries

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)Andy Page,Bristol,Uk

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)

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)

OS

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)

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)

Yes, but there are MinGW-based cross-compilers in several Linux distributions.TorLillqvist (talk) 07:36, 4 August 2009 (UTC)

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)

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)

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)

MinGW 4.3.0 is in preview for a good reason

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)

License

The text under Comparison with Cygwin claims:

 [I]ts runtime shell MSYS is licensed under a permissive license.

I am not sure this is correct; for example, the MSYS_LICENSE.rtf which came with the release installed here begins with MSYS contains several different other packages. Most of those packages are licensed by the GNU Public License (GPL). Yet I am not a lawyer, neither am I the person which wrote it in the first place so I do not want to directly erase it. AntoineL (talk) 12:10, 29 July 2008 (UTC)

The mingw home page states that the "base runtime", which I assume to mean the shell environment provided in the MSYS package, is in the public domain; the GNU-derived packages included in the MSYS installer are licensed under GPL; the WinAPI headers appear to have a BSD-like license with an anti-copyleft clause. Anyone else want to try interpreting?[1] Ham Pastrami (talk) 13:34, 29 July 2008 (UTC)

MinGW consists of multiple packages, most of them either have exceptions to GPL (i.e. GCC, binutils), use weak copyleft, or are only used at build-time (i.e are just tools, not libraries). MSYS is a Cygwin fork, and has lots of GPL elements. Applications and libraries built with MinGW don't have any licensing problems, most of the time (the compiler and all base headers won't require the code to be GPL-licensed). Meanwhile, applications and libraries built with MSYS are, AFAIK, GPLed, all of them, because they all depend on MSYS runtime library. Note that the only purpose of MSYS is to provide an environment for running programs that can't be ported natively to W32 (such as the 'bash' shell to run scripts - i.e. Autotools). Since MSYS is only used at build-time, it does not create any licensing problems for programs built with the help of MSYS.

MinGW can be used without MSYS, if some non-autotools build system is used (CMake, SCons, etc). L.R.N (talk) 18:01, 8 March 2013 (UTC)

GNU Core Utilities

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)

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)

"Do not need Windows"?

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)

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)

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)

The article doesn't say that. Developers can (and should) have separate testing environments anyhow. Ham Pastrami (talk) 02:13, 23 April 2009 (UTC)

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)

Copyleft and source code remarks

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)

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)

FAQ and History Link

I saw on the article that the MinGW FAQ leads to [2], although still valid, there isn't a "faq-what" anchor. The history link pointing to [3] isn't valid anymore, its now [4]. Why was my edit reverted? 203.142.61.45 (talk) 03:31, 5 August 2009 (UTC)

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)

Misleading information and edit wars

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)

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)

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)

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)

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)

mingw64 fork

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)

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)

This is absurd. I can't believe there are people so ignorant and/or hateful that they would argue that Mingw-w64 is insignificant and has no relation to MinGW. I guess this is proof that there is no hope for remerging. Come on, someone at MinGW, go on record with the truth, show that there are good people in your project and we should still consider you as our sister project, or I will accuse MinGW (once known as Mingw32) of being the actual fork itself, and Mingw-w64 being the main thread. Prove it otherwise. This is like something out of a Kafka novel. Xenofears (talk) 03:27, 14 August 2009 (UTC)

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)

There is no "clarification" required. Anyone who has been part of MinGW that isn't totally ignorant wouldn't bring up such a ridiculous question/accusation/judgement. I do not wish to continue this discussion. Bye! Enjoy the silence. Xenofears (talk) 03:59, 15 August 2009 (UTC)

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)

Mingw-w64 version of headers and runtime does not bear any obvious signs of being derived from mingw.org, and the rest of the toolchain (GCC, binutils) is from upstream anyway. Please don't claim mingw-w64 to be a mingw.org fork, unless you have a solid proof. L.R.N (talk) 18:01, 8 March 2013 (UTC)

Domain Expired (obsolete)

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)

Cyberwizzard (talk) 15:00, 2 February 2010 (UTC) I added an explicit note about the hijack of the domain to the page as I found multiple forum posts about the disappearing mingw.org site but nothing on normal pages. Perhaps hijacking is a strong word here but since the domain is for a popular project, registering it for a 3rd party should be considered rude (at least).

As soon as the domain has been restored or a new domain is assigned, the note and this section can be removed again (unless someone thinks it is historically relevant, which would require a new section).

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)

As of 2016-02-18 the domain is fine. --johayek (talk) 17:04, 18 February 2016 (UTC)

Mingw-w64 will need its own article

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)

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)

Infobox added Helios crucible (talk) 06:33, 17 December 2014 (UTC)

And I've summarized it in the lede. Diego (talk) 08:59, 29 May 2015 (UTC)

Version number?

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)

oh look! cygwin fanboy here

"The combination of MinGW and MSYS provides a small, self-contained environment that can be loaded onto removable media without leaving entries in the registry or files on the computer. Cygwin Portable provides a similar feature that is far more robust."

Zloidooraque (talk)

"MinGW links by default to the Windows OS component library MSVCRT, "

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)

Semi-moribund project

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)

Legitimate version history.

There is no obvious legitimate version history anywhere, but according to this post from one of the developers, there are illigitimate versions out there, confusing people.

http://https..osdn.net/projects/mingw/lists/archive/users/2019-March/000260.html

On 10/03/19 15:59, Test User wrote: > MinGW 5.3 is installed on my PC.

If this is so, then you did not get it from us, and it has been illegally named, infringing our registered trade mark. There is no such legally named entity as MinGW 5.3.

Regards, Keith. (That name is one of four at the heart of MinGW development.)

I found it difficult to find a list of legitimate version numbers, and I got those from extensive exploration of an OSDN FTP archive in Japan! It MUST be easier than this to get reliable information! Someone needs to post a definitive list and put it front and centre on the main MinGW page here. As a starting point, here are the four I am certain of: "6.3.0-1" "7.3.0-1" "8.2.0-5" "9.2.0-3". (The digit after the dash is the latest minor variant in each version case.)

The OSDN arhive did not include earlier or later versions, so I'll leave the rest of the work to someone with knowledge of official sources.

81.187.19.110 (talk) 13:45, 23 November 2024 (UTC)