Windows version of Ruby (proposals)

Dennis Newbold <[e-mail]> wrote in message news:<Pine.GSO.3.96.1020320113603.22242B-100000@shell2>...
> On Wed, 20 Mar 2002, Ron Jeffries wrote:
> 
> <--- snip, snip, snip --->
> > 
> > But there's no scapegoating implied. If Ruby is to be as popular as it deserves
> > to be, my opinion is that there needs to be a good Windows version. While
> > Windows isn't the best of anything, it's biggest. In my opinion it's not a good
> > idea to ignore it.
> > 
> Well, as I indicated earlier, you can use Ruby to do pretty much anything
> on Windows that you want to do using the Win32:: module.  However, its not
> quite as simple and straightforward as using Ruby on Linux, since the
> support is added on, rather than built-in.  And since Matz has indicated
> that he really hopes that Ruby will take off and become incredibly
> popular, it seems that having more built-in support for Windows services
> would be a big step in that direction.  Unfortunately, my understanding is
> that he has no real in-depth knowledge of the Windows OS, and has no real
> interest in developing or obtaining that knowledge.  So, the logical
> solution would be for him to "appoint" a knowledgeable and capable
> assistant whose job would be to develop a set of built-in modules,
> classes, etc. that would be compiled in when building Ruby for Windows,
> but not when building Ruby for *nix.  Obviously, this would require alot
> of ongoing coordination to keep things "in sync" as Ruby development
> progresses.  I think I have the necessary knowledge base as I've done
> quite a bit of work with both Windows and Linux.  Unfortunately, with a
> full-time job, wife, and kids, I don't have alot of free time.  So, unless
> we can get a company (ActiveState maybe?) to pay a few people for the
> time they spend working with Ruby source code, I'll have to opt out.
> 
> Any other volunteers?  Also, if anyone on the list has access to Matz, it
> would be interesting to see if he is interested in doing something along
> these lines.
> 
> Dennis


My newsfeed has been down all day.  I had no idea how much traffic
this thread generated. So, since my newsfeed is still down I'm using
google...



Anyway, Apparently popen works on 1.6.6 so that leaves only fork not
working (is there anything else?).
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?)

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?


III. Why doesn't Rubicon work under Windows?

What are the issues with Rubicon under Windows?

Phil