Ross Ridge wrote: > MSVCRT.DLL has been a standard system compent of Windows since at least > Windows 98. Many other system components depend on it. Essentially, > MSVCRT.DLL is an "undocumented" part of the Windows API. It's not > exactly "endorsed", Microsoft would rather you use it's current > compiler and runtime, but it is the standard "official" Windows system > C library.
Martin v. Löwis wrote: > 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.' Exactly, it's the standard Windows system C library. > The SDK stopped including an import library for it (I believe earlier > versions of the SDK still had an import library). An import library for it is easy enough to obtain. You can make your own, or just grab the one from MinGW. If you insist on a Microsoft source for it then you can find it in the Windows DDK. > Regardless, there is no version of the MS C++ library that links against > msvcrt.dll. The version of the MS C++ library in Visual Studio C++ 6 links against MSVCRT.DLL. > So if Python is linked against msvcrt.dll, you can't really build C++ > extensions anymore (with MSVC), unless you are certain that > mixing CRTs causes no harm for your application. Python 2.4 is linked against MSVCR71.DLL, so you can't really build C or C++ extensions anymore with Microsoft's current compiler either. Ross Ridge -- http://mail.python.org/mailman/listinfo/python-list
