Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Parent Full thread

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.)

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.

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.

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!

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.

Reply on news.ycombinator.com