> Well, my hope was to *not* have to rebuild things like pdcursesÍÃut > remember that I was trying to build against VS2005, not mingw (I'm > *still* not convinced that mingw is a good idea because it depends on > such an old C runtime), so the incompatibility issue mattered much > much much more. I suppose you can link against a newer version if desired [1], though it's true that the project goes stagnant quite a bit. I suppose my only concerns with the change are 1) are there subtle errors, like you do an ALLOC_N and then the library frees it, so you can't control it, resulting in a binary incompatibility? 2) Apparently you cannot use structures across different runtimes is that right [2]? I suppose that's not a problem? There is definitely some utility to this proposal, though: 1) It will official "bless" a specific msvcrt.dll version [msvcr90.dll? [4]] This apparently drops support for windows 98, but who cares [3] :) Binaries would need to be built [re-built] using VC2008 or mingw cross compile linked to that dll, is that right? I think that would bring some sanity to the windows environment as currently it's pretty fragmented. 2) It allows mingw built binaries to interop with VC ones--binaries are much faster if built by gcc [1 #5]. Do the core folks favor VC2008 or any compiler at all? It appears that as long as you link to the same DLL the two are compatible. Another option would be to release a mingw only OCI linked against msvcr90.dll, then instruct extension developers on how to release binaries that "pretend" to be mingw though they're only "mingw compatible." Or perhaps rubygems could be patched to recognize compatible binaries. Thoughts? -=r [1] http://www.develer.com/oss/GccWinBinaries [2] http://luabinaries.luaforge.net/manual.html#LuaBinariesCompatible [3] http://rcecafe.net/?p=33 [4] msvcr90.dll apparently? from http://www.codeguru.com/forum/archive/index.php/t-456623.html though apparently it's possible to force link against msvcrt.dll with all its inconsistencies :) Would mingw be forced to link against msvcr90.dll then? See also http://jove.prohosting.com/iwave/ipython/issues.html as an example that it is possible to at least link against msvc7.1.dll with success. See also http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx for a reiteration 'it is named msvcr90.dll now"