Eli Green <eli.green / codedogs.ca> wrote:

> Ok, I wanted to get away from the theory and conjecture thread of the
> make-ruby-better-under-Windows topic

> 1. What parts are slow?

well, here's one case where cygwin outperforms the other interpreters:
http://www.ruby-talk.com/cgi-bin/scat.rb/ruby/ruby-talk/21955

My guess is that enough CFLAGS twiddling should bring the mingw version
on par, speedwise... But it could be more subtle, like a malloc lib 
better tuned under cygwin, or better suited to the current ruby GC 
mechanism... That'd require profiling I imagine. 
Also, since "eban" (eban / ruby-lang.org) produces binaries for both 
cygwin and mingw, (s)he may help. Maybe not an english NG reader, 
though...

> 2. What parts are unreliable? (I think networking is the big ticket item here)

Dunno. We still need _examples_ of unstable networking code under cygwin.
BTW if the attention of a cygwin maintainer is brought to this thread,
I'd like to let them know that their hard work is appreciated. The cygwin
tools suite is the very first thing I install on any Windows system I 
work on - along with vim. Emulating an OS API under another is no slight
undertaking, and they've succeeded to a very remarkable -if not complete-
degree. Thanks to Cygnus/Red Hat for allowing this.

> 3. What parts require Cygwin? (popen?, fork?)

I don't think it matters that much. Native (ActiveState) ports of 
perl and python have been very succesfull and carry a large proportion 
of their libraries under Win32. Given the open source nature of the 
project, mingw makes more sense than VC, though.

HTH,

Bernard.