I wonder what they're up to...
I wonder what they're up to...
I'm not sure how static linking would work, but definitely for dynamic linking, you can download msvcrt.dll (or whatever) from Microsoft and link against that using the GNU linker `ld' provided by MinGW.
Also, if there were a licensing issue, then nobody would be able to distribute binaries compiled by MinGW, yet there are many small and large businesses that shamelessly do so. Are all of them violating the GPL?
I don't think so, especially if they dynamically link, because what GPL3 code is there involved?
Step 1: I write my own code. I can license it however I want.
Step 2: I use MinGW to compile it. MinGW links it against the native Microsoft libraries such as msvcrt.
Step 3: I distribute my binary. The binary contains code linking against Microsoft libraries and it contains my own code, which is under any license I want as long as it doesn't contradict Microsoft's license agreement for linking with their libs.
Where's the GPLv3 code? GNU and FSF explicitly say that their compilers can produce binaries under any license you want, and you are only restricted in the choice of license if your binary contains object code from GPLed libraries (which is a completely separate concept than the license of the compiler / linker stack). So for a silly example, if you had a C library licensed under a license that only allows you to run the code on a satellite in space, you could legally produce dynamic or static binaries using gcc and this C library, and you'd only be bound by the restrictions of that C library's license and any other object code that is dynamically or statically linked to your code. The license of the compiler infrastructure intentionally does not touch the license of the produced binaries, any more than encoding MP3s with LAME means that you have to license them under the GPL, or that producing .odt files with OpenOffice means that you have to license them under the GPL.
You must be thinking of Cygwin, which ships its own C library and links against a Windows emulation of libc and libstdc++, etc. and emulates POSIX calls like fork() and exec().
AFAIK the only purpose of MinGW's Win32 API libraries (both static and dynamic) is to give GCC and the linker sufficient information to produce a binary that, at runtime actually does link against Microsoft's implementation.
Lending credibility to this idea is the file size of even the static archives (.a files) of Win32 libs in MinGW: they're a couple kilobytes apiece. No way you can implement all of the win32 API in a megabyte or two.
Also, if some company writes a library that you want to link against your MinGW executable, and they link against the MSVC libraries, you can still link their library into your MinGW-produced executable.
There are some technical complexities as detailed at http://www.mingw.org/wiki/MixingCompilers but these can be overcome, as the article suggests.
Also, they aren't going to remove support for VS2010 or programs that link against it, so there's really nothing to panic about. True, people who want to use new APIs and capabilities introduced in VS11 won't be able to do so without buying a licensed copy. But people who want to use APIs from the VS2010 generation are free to do so in native code, .NET, or pretty much anything that's offered, for $0 using the Express editions. That will not change with Windows 8.
And if you ask me, there are going to be very few people who have a legitimate need to want any of the native enhancements that will have been made between Windows 7 and Windows 8. Most things you'd want to do on Windows are already doable with the free VS2010 Express tools. And existing free software packages are almost certainly not going to use the new APIs, mainly because I doubt they'll be that useful, but also because you can pretty much do what you want with VS2010 (or even earlier if you use a rich wrapper library like Qt or JUCE).
The people who will really want to take advantage of all the VS11 enhancements are the proprietary developers who write Windows-only applications. But since the FOSS movement very often writes software for Windows using cross-platform libraries to begin with (so that the software also runs on e.g. Linux and BSD), all we'd be doing by accessing those new native APIs is requiring someone to have a copy of Windows 8 to run our free software. I highly doubt that will happen very often.
So stick to what works; it works extremely well as-is. Use MinGW or VS2010 Express + Windows SDK. As long as M$ doesn't drop support for old APIs (and they definitely couldn't get away with dropping all of VS2010), we can continue to write effective FOSS programs that run on Windows without licensing worries.
And hey, nothing's stopping MinGW from supporting the new native APIs, and nothing's stopping Mono from supporting the new CLR APIs in .NET 4.5. Chances are that both projects will catch up in due time, and you'll be able to actually access those new Windows 8-only APIs (if you insist) using entirely free software (the base operating system excluded, of course).