[ruby-core:22811] Re: Moving ruby 1.9.1 forward on windows

> 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"