From: ptkwt@...1.aracnet.com (Phil Tomson)
Date: 2002-03-19T10:05:39+09:00
Subject: Re: Development of Windows version of Ruby

In article <3C966FC9.9170048A@hurstlinks.com>,
Guy N. Hurst <gnhurst@hurstlinks.com> wrote:
>Phil Tomson wrote:
>> 
>> Now that we've dumped the cygwin requirement for the Windows version of
>> Ruby and new releases are compiled with MSVC it apparently leaves some
>> holes in functionality as compared to the Unix versions of Ruby.  For
>> example, popen doesn't work anymore on Windows as of the 1.6.6
>> release (does fork work?) because we used to rely  on Cygwin for this.
>> 
>
>I think this is a difference between Unix and Windows, and
>has little to do with Ruby.
>
>> Are there any plans to patch these functionality holes?  Would Mingw help?
>
>I wouldn't expect any.
>
>> I'm just curious, I don't do much on Windows anymore, but I do think that
>> some folks will miss some of this functionality and newbies who expect
>> that it should be there could be disappointed.
>>
>
>As far as I know it *never was* there. Even perl on windows has
>to live without fork, notwithstanding the rudementary substitute
>they came up with. The closest I got was perhaps spawnv, which
>I managed with wxpython, but it still wasn't useful enough at the time.
>
>I am in favor of dumping cygwin in favor of using mswin because
>windows is not unix. Render unto windows what belongs to windows,
>and unto unix what belongs to unix. Those who use windows are more
>disappointed to see the problems cygwin causes, I think, than 
>non-windows users are when their unix-based app doesn't fork properly,
>for example. 
>
>Even certain things related to processes are
>inconsistent between unix versions (linux vs bsd for example), such
>that certain ruby methods don't work on both for them, either.
>(I say this from an experience I had a year ago).
>
>In short, I am just writing this to cheer for the mswin version :-)
>

I'm not disagreeing with the decision to abandon cygwin.  It will probably 
be better in the long-run.  However, when I used Ruby on Windows (using 
cygwin)I did make use of popen in a script that needed to run on both 
windows and Unix.  Cygwin emulated popen for me and so  it worked (you 
could argue that I should have used threads for cross-platform concurrancy
and you'd probably be right, but at the time popen worked as far as I can 
recall).  So the question is whether we should put any effort into making 
some things like fork and popen work on the Windows platform so that it 
looks like they work the same way as if you used Ruby under UNIX.  Cygwin 
does it but introduced a lot of other problems.  What about MingW?  Does 
it emulate these sorts of things as well?  What problems does it 
introduce?

BTW: I used Perl for several years and as I recall there was always a 
demand for things like 'fork' and 'alarm' (Ruby's timeout is very much 
nicer than Perl's 'alarm', but I bring it up here as an example) to work 
under Windows Perl. [In fact, it was one reason that caused me to take a 
serious look at Ruby as an alternative to Perl for some Windows scripts I 
was developing over a year ago]. ActiveState worked on getting a lot of 
these things to work in their Windows version of Perl (though, last I 
checked 'alarm' still doesn't work). Personally, I think we should try to 
expend some effort to emulate some things like 'fork' and 'popen' in 
the Windows version of Ruby.  What happens in the Ruby 1.6.6 Windows version 
when someone uses these functions?  

Alternatively, perhaps some of this functionality can be 
provided by a module (Win32::popen, Win32::fork - I've got a 
Win32::Process module that can be used to star/stop/kill processes under 
Windows).  The only problem to that approach is that if someone writes a 
program that they want to run on both Unix and Windows the Win32:: stuff 
will get in the way.

Phil