I am entirely unconvinced of this perceived incompatibility. Yes, by default,
mingw produces .so shared libaries and .a archives. However, have a gander at
this:

http://starship.python.net/crew/kernr/mingw32/Notes.html

Mingw and VC can apparently live together in peace and harmony. I have gotten
ruby to compile under Visual Studio, producing a .DLL of the core Ruby stuff
and a .exe linked to that DLL. This is how Python and Perl do it, with obvious
reasons/advantages.

See my recent comments on the Wiki about the separation of the user
distribution and the (module) developer's distribution:
http://www.rubygarden.org/ruby?FutureWindows

That being the case, whoever takes over building the "official" winruby
distribution doesn't even need to tell people what compiler they used. :)

Having an official executable that everybody could produce binary modules
against would be wonderful.

There is one problem ... and if there are any Windows people with a solution
to this out there, I'd love to hear it ... exported symbols in a Windows DLL
need that damned __declspec(dllexport) in front of them! And I sure as hell
don't want to be the one who has to insert that in front of every public
function in the ruby source ... so if somebody knows how to force LINK.EXE to
export every symbol (like ld does), that'd be very welcome information.

> I'm still not convince of the incompatibility of linker format, I still see
> prior art in the
> fact that I have several mingw apps linked with win32 dlls built with MSVC.
> I actually have no problem with MSVC being the standard (contrarely to the
> way I
> sound when I read myself) but its just that if it is the case there needs to
> be a group
> responsible and dedicated to port and distribute as many extension as
> possible
> for this format.  I don't believe the developpers will do it.
> Benoit