Hacker News Reader

Comment by xorblurb | Hacker News Reader

Cygwin and Mingw are not really comparable. And if you are thinking about MSys, it's a fork of Cygwin, so...

MSYS is an ancient branch of a common code base with Cygwin, which only needs just enough POSIX content in order to compile the utilities which are included in the toolchain which MSYS supports: the toolchain known as MinGW. That toolchain itself doesn't link programs against MSYS; it links programs against Microsoft's redistributable C run-time library (MSVCRT.DLL). Essentially, MinGW is a cross-compiler.

MSYS is a kind of "non-user-serviceable area" that you wouldn't deal with unless you were hacking on MinGW itself. Say you wanted to add some missing utility to MinGW, and there was some issue between MSYS and that utility requiring MSYS hacking.

If you think that you have a POSIX program that could benefit from being linked against MSYS, you're almost certainly better off just using Cygwin to port it. And now you can redistribute the Cygwin DLL with that program without tainting the program with the GPL.

MSVCRT.DLL isn't redistributable, it's a system component. There are some changes recently that I haven't kept up with to make it easier to target a single C library, but the redistributables all had the compiler version in the name and were not compatible across versions.

See here:

https://support.microsoft.com/en-ca/kb/2977003

"Visual C++ Redistributable Packages install runtime components of Visual C++ Libraries on a computer that does not have Visual C++ installed. The libraries are required to run applications that are developed by using the corresponding version of Visual C++."

And an overview here:

https://msdn.microsoft.com/en-us/library/ms235299.aspx

Visual C++ libraries are not a core component of Windows; they are run-time support for Visual C++ programs. Microsoft calls them "redistributable".

If you write a program which depends on this, it behooves you to ship the exact version you're testing with and install it in the same directory as your executables. (See the "corresponding version" remark above from Microsoft themselves!)

(Which is why it is a myth that MinGW makes "native" Windows executables that don't need anything; in fact they rely on some program having been installed before them which rudely put some version of the MSVCRT.DLL into the System folder.)

No, none of those ship MSVCRT.DLL (at least, none of the earlier ones, as I said, I stopped paying attention).

Here's MSDN talking about it being a system component:

https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).a...

At least since .NET 2003. It's handled differently in 2015.

Wow, thanks for clearing up a major misunderstanding.

There's a difference between the unversioned MSVCRT.DLL and the versioned MSVCR100.DLL, MSVCR120.DLL, etc. libraries. MSVCRT.DLL is technically private API, for the Windows OS's own use, and its API changes on OS releases. The versioned MSVCRnnn.DLL are intended to be shipped with applications, and that's what's in the download links you provide.

https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...

The trouble is (AIUI) that the GPL has an exception for system libraries, and MSVCRT.DLL is shipped with the system and MSVCRnnn.DLL are not. Microsoft legally allows you to redistribute MSVCRnnn.DLL, but does not provide source. Therefore, distributors of GPL apps linked against MSVCRnnn.DLL have no way to satisfy their legal obligations. So MinGW makes life easier for GPL apps, which are a significant part of the target audience, by linking against MSVCRT.DLL instead. This is worse from a software engineering point of view because you're using private / unstable API, but it is not illegal, and it lets you avoid the GPL issue.

The program that put MSVCRT.DLL in a system folder wasn't being rude; it was the Windows setup program itself, which was perfectly allowed to put it there. MinGW is being rude by looking for it. (However, if an app linked against one of the versioned libraries did not ship with the versioned library, then yes, it would be expecting some rude app to have copied the versioned library into the system folder.)

Ouch! MinGW is really in a limbo, sticking its fork into the proverbial toaster. Microsoft can change behaviors in MSVCRT.DLL, which can break MinGW programs.

Now I'm even more motivated to stop using MinGW.

I have heard that it's possible to talk MinGW into linking against MSVCRnnn.DLL instead, with some effort. And then you have to figure out how to ship the redistributable, both physically and legally, but if you can do that, more power to you. Here's a plausible-sounding set of instructions:

http://www.pygame.org/wiki/PreparingMinGW

Say, what about the msvcrt from the Wine project?

http://source.winehq.org/git/wine.git/tree/HEAD:/dlls/msvcrt

Huh. That's a really interesting idea. I'd be worried about whether it translates to UNIX calls, but it looks like it mostly translates to Win32 calls (that WINE then emulates).

I don't know enough about MinGW to try it, but seems worth a shot!

MSVCRT.DLL is what programs compiled with Visual Studio 6.0 link to. So I think it's safe to expect MS retaining compatibility for the forseeable future.

> MSYS is a kind of "non-user-serviceable area" that you wouldn't deal with unless you were hacking on MinGW itself

If so, why did they actually create MSYS(2)? Why not just compile MinGW executables using gcc under Cygwin?

> Why not just compile MinGW executables using gcc under Cygwin?

I have no idea. A cross toolchain for making Windows programs compiled with GCC, and linked with MSVCRT.DLL could be made available as a Cygwin package. All of the utilities for controlling the build can just be the Cygwin ones; all that is needed is the cross-gcc.

It used to be just "gcc -mno-cygwin" would suffice. Now the cross gcc is available separately, choose one of i686-pc-mingw32-gcc, i686-w64-mingw32-gcc, or x86_64-w64-mingw32-gcc.

Reply on news.ycombinator.com