>of their libraries under Win32. Given the open source nature of the
> project, mingw makes more sense than VC, though.

That makes perfect sense, although I do not agree from a pragmatic point of
view.

1)  so used to having VC around that I don't really think about those who
don't.
But I think that most developers who don't have VC around also don't have
Windows around - at least as a development environment.
I for one would probably choose Linux the moment I settled for gcc.
Why would I want to use gcc on Windows? The only reason I can think of is
writing extensions to Ruby.

2) The major issue is the object / linker format. Any compiler with a
compatible linker format will do. I don't know gcc well enough to know if it
can support standard Windows (i.e. VC) object format. From what I have heard
it doesn't. I may just be a question of finding the proper compiler switch.
The free X86 assember NASM supports many object formats for many OS'es,
incl. the std. windows format.

3) What does MinGW provide in terms of windows support? Microsoft has
published a Win32 SDK which is intended for VC as well as other compilers
such as Borlands. The SDK can be downloaded here
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ In principle this
means VC is not required. I.e. the goal should be to support Ruby under the
platform SDK in standard linker format - not necessarily using VC.

4) Not considering the linker problem, MinGW is also a third party
dependency. So is platform SDK, but it is a direct extension to the
operating system.

5) Future support on new windows platforms - like XP, can be problematic if
it is not the platform SDK that is being used (directly or indirectly via
VC).

I consider MinGW and Cygwin to be tools used to make it easier to port unix
apps. But if Ruby has no apparent reason for requiring MinGW, using the
platform SDK, this is the best way to support Ruby under Windows.

I also really don't see a problem with unix/posix process and thread api's
not being supported. If Ruby is going to use native threads, it should be
done in a way that abstracts away from the operating systems at the Ruby
level, not at the C api level. I should use NATIVE threads, not a layer to a
standard interface. This will require different source for Windows and Unix.
But there is also support for pthreads on Win32:
http://sources.redhat.com/pthreads-win32/ if it has to be. Don't know it,
but it seems to be using standard linker format dll's and libs.


Mikkel