From: Christian Boos <cboos@...>
Date: 2002-03-21T19:24:20+09:00
Subject: RE: Windows version of Ruby (proposals)

Some thoughts on the 2 first Windows issues, plus a 4th one...

> -----Original Message-----
> From: Phil Tomson [mailto:ptkwt@aracnet.com]
> Sent: Thursday, March 21, 2002 5:05 AM
> To: ruby-talk ML
> Subject: Windows version of Ruby (proposals)
> 
> 
> Dennis Newbold <dennisn@pe.net> wrote in message 
> news:<Pine.GSO.3.96.1020320113603.22242B-100000@shell2>...
> > On Wed, 20 Mar 2002, Ron Jeffries wrote:
> > 
> > <--- snip, snip, snip --->
> > > 
...
> 
> Anyway, Apparently popen works on 1.6.6 so that leaves only fork not
> working (is there anything else?).

Ok, popen works, but not Open3::popen3.
This means it is NOT possible on windows to differentiate between
stderr and stdout of a sub-process. When you create one using 
`` (or the syntactic equivalent %x{}), you get in a string the 
_mixed_ output from both stderr and stdout.
I would love to be wrong, but so far I don't see any workaround.

> So, I see three main issues here: fork, pathnames and Rubicon (as in
> why doesn't Rubicon work under Windows?).
> 
> 
> I. fork
> 
> There are two main camps here:
> 1) fork should 'work' on both platforms (it should be emulated on
> Windows)
> 2) fork doesn't need to work on Windows since the OS doesn't have fork
> (after all, you wouldn't expect Win32API stuff to work on UNIX -
> that's a good argument actually)
> 
> 
> And there were several proposed solutions that fell into three
> catagories:
> 1) do nothing (goes with #2 above) Windows programmers don't expect to
> have fork
> - a compelling argument, except that some folks are writing scripts
> that are to run on both Unix and Windows (I was doing this about a
> year ago).
> 2) emulate unix's fork on Windows when Ruby's fork is called (either
> by calling CreateThread or CreateProcess) (and it was pointed out that
> ActiveState Perl's
> implementation of fork under Windows is a bit iffy)
> 3) Make it so that no one expects fork to work on Windows by putting
> fork in some other namespace like: POSIX::fork
> (did I miss any?)

I would vote for that. Not only it would make the issue clearer,
but it would allow for a smoother transition path once emulation
solutions are found, or even allow for alternative workarounds.

> 
> 4) My proposed (near-term) solution: Documentation.  Put something in
> the FAQ about fork not working under Windows and offer some
> alternatives.  If the script is to work cross-platform, then something
> like this could be proposed:
> 
> #don't expect this code to work ;-)
> if RUBY_PLATFORM =~ /win/i
>    p= Win32::Process.new(...blah...) #I have a module like this, it's
> on RAA
>    #then you can do things with p: p.kill, p.id, etc
> 
>    #or maybe something with Win32API(CreateProcess...)
> elif RUBY_PLATFORM =~ /ix/i
>    fork...
> end
> 
> (long-term) if the 'fork should work on all platforms via emulation if
> necessary' camp is still not happy, then perhaps we should have
> someone investigate how it was done in ActiveState Perl.
> 

> II. Pathnames (someone brought this up somewhere in the thread)
> 
> The old backslash vs forward slash problem + Windows has drive names
> which UNIX does not have.
> 
> 1. Is this a real problem?
> 2. proposed solutions?
> 

I don't thing it's a problem. My experience is that on Windows
you can safely mix '/' and '\' in ruby pathnames.

-- Christian