MinGW and Python

["Martin v. Löwis"]

Edward Elliott wrote:
>> Well, there is no native C library on Microsoft Windows: the system
>> simply doesn't include an official C library (I know there is crtdll.dll
>> and msvcrt.dll, but these aren't "endorsed" system C libraries).
> 
> don't know what you mean by "endorsed".  does it lack features of the C89
> ANSI standard?

There isn't an import library for these DLLs anywhere, and Microsofts
documents it (msvcrt.dll) as not intended for application use:

http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx

'The msvcrt.dll is now a "known DLL," meaning that it is a system
component owned and built by Windows. It is intended for future use only
by system-level components.'

>> For Windows, that would require not to use any of the standard C
>> functionality, since the system doesn't provide that functionality out
>> of the box. 
> 
> That would be a problem then.  So what happens when you compile python with
> msvc, and why can't mingw just replicate that?

I link with msvcr71.dll (currently). To distribute Python, I need to
include a copy of msvcr71.dll, which I can, because the MSVC license
allows me to redistribute that DLL.

When I link with mingw, I have a choice of DLLs to link with, including
msvcrt.dll, msvcrt4.dll, msvcr71.dll, and perhaps others - I don't even
need the DLLs on my system to link with them.

However, I cannot redistribute these DLLs when I compile with MingW
(unless I also have a copy of VS.NET - I would have to reread its
license to find out whether it requires that the application is actually
built with MSVC to allow for redistribution).

Regards,
Martin