From: ptkwt@...1.aracnet.com (Phil Tomson)
Date: 2001-10-02T11:51:04+09:00
Subject: [ruby-talk:21914] Re: Let's work on Windows support

In article <3BB8E096.C819F3BD@uark.edu>,
Albert L. Wagner <alwagner@uark.edu> wrote:
>
>
>"Guy N. Hurst" wrote:
>> 
>> Robert Hicks wrote:
>
>I currently develope on both windows at work and linux at home. 
>My source, from either platform, runs on either platform.  The
>only discrepancies I have encountered are with GUI differences,
>not Ruby.
>
>> 
>> I think ruby should be delivered from the cygwin womb and learn to
>> stand on its own on the windows platform. You might hear a brief outcry,
>> but that should be considered normal ;-)
>
>The outcry will be loud and more than brief.  This remark seems
>somewhat insensitive.
>
 
Not really.  I don't think he's saying that we just dump Windows, but that 
we need to consider an alternative to cygwin which we control.  If we 
embark on that road it will be fraught with bugs itself for quite a while 
(hence the comment about the outcry), but perhaps that is the best road to 
take in the long run.

There seem to be a couple of big issues here:
1) cross platform compatiblity - we'd like scripts (even scripts which do 
things like process control for example) to run on major platforms with as 
little change between them as possible - preferably with no changes 
to scripts at all.

As an example: You'll still have a 'system' command in the Windows 
version.  Currently, the underlying code for making 'system' work is 
written from a Unix perspective and we rely on cygwin to make the 
translations for us (correct?)  If we were to dump cygwin, then we'd need 
some underlying C code that (if you're building on Windows) would call 
'CreateProcess' from the Win32 API instead.

2)Control - The Ruby community relies on an external component, 
cygwin, 
which provides a unix compatibility layer for Windows.  So currently, 
when someone finds a problem related to cygwin in the Windows version of 
Ruby, people tell them to try mingw, or a build done with VC++ (and 
each of those solutions pose their own sets of problems) The Ruby 
community doesn't control cygwin, so bugs in cygwin end up making the Windows 
version of Ruby look bad - but there isn't a lot we can do but submit 
bugs to the cygwin folks.  Now, whether or not we can do better is still 
an open question (or at the very least, how long it will take to do 
better).  

Someone earlier in the thread asked why Python (and I could add Perl) 
doesn't have this problem - I think the answer is that ActiveState has 
done a lot of work on the windows ports of those languages.  Prior to the 
ActiveState port of Perl for Windows, I think the Perl community struggled 
with a lot of the same issues.  One solution would be to convince 
ActiveState to do a port of Ruby for Windows, but I'm not sure they feel 
that the incentives are there yet.  What would it take to convince 
them?

Phil