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 -- http://mail.python.org/mailman/listinfo/python-list
