From: Dennis Newbold <dennisn@...>
Date: 2002-03-20T05:35:31+09:00
Subject: Re: Development of Windows version of Ruby

To the best of my knowledge, Ruby DOES work well on Windows.  I have
written a fairly large Ruby program which runs on Windows and interfaces
to a specific third-party DLL which in turn interfaces to a 3rd-party
add-on card.  It worked fine.  The issue under discussion is not "how
can we make Ruby work well under Windows".  The issue being discussed is

"What can we do to make a program written to run under a UNIX OS, run
 equally well under Windows".  This is not a question which is unique to
 Ruby.  A program written to run under UNIX which uses the fork() system
 service will have a really difficult time running under Windows.  This
 is true regardless of the language it is written in -- C, C++, Java,
 Pascal, or whatever.  This is because the user level program makes use
 of run-time library services, and the run-time library in turn makes
 use of OS services.  If the underlying OS does not provide a service
 which does essentially the same thing as fork() (you can call it anything
 you want, but it has to do the same thing), then the run-time library
 is pretty much stuck.  You can't at the user level "emulate" or "fake
 out" the creation of a new child process with an independent thread of
 execution which has its own separate data space whose contents
 exactly match the contents of the parent process' data space as they
 existed at the time the child process was created.  A whole bunch of
 very creative people at ActiveState have been thinking about it for a
 long time, and haven't come up with anything.  Another bunch of equally
 creative people at Cygnus -> Redhat tried very hard to do this and
 only succeeded in making a rather unwieldy and unpredictable hack.

 IMHO, the only really feasible way to port a UNIX program which uses
 fork to a Windows platform is to have a real, live programmer who is
 reasonably familiar with both OS's sit down, read the code, understand
 why the program is using fork, and come up with a functionally similar
 way of doing the same thing under Windows.  Many times, this is not all
that difficult, and only entails a little bit of conditional compilation
or something like that.  This is because often, a fork is followed
immediately by an exec, and in Windows this can be done via a single
Windows API call.  Also, if the child process does stay around and do
stuff for awhile, perhaps it uses only its own local data variables,
and does not have any need to access data which came originally from
the parent process.   In this case, often the fork() call can be replaced
by a call to create a thread, which shares the address space of the
parent process.  This is the best way to address the problem of using
fork.  And, as the problem is language-independent, the solution is
also.  The downside is that its not a "no brainer" thing which is buried
in the guts of a library.  It requires that the programmer himself do
some thinking and analysis.  Well -- thats what they're paying us for,
folks :)

Cheers

On Tue, 19 Mar 2002, Ron Jeffries wrote:

> Something like all the PC programs in the world are written for Windows.
> Something like all the programmers in the world program on Windows. Something
> like all the PC users in the world run Windows.
> 
> Whether we like it or not, those statistics are pretty close to exact.
> 
> For Ruby to take on the stature it deserves, it needs to work well on Windows. 
> 
> Even more important, at least to me: if I'm to use it, it needs to work well on
> Windows.
> 
> Please govern yourselves accordingly.
> 
> Cheers,
> 
> Ronald E Jeffries
> http://www.XProgramming.com
> http://www.objectmentor.com
> I'm giving the best advice I have. You get to decide whether it's true for you.
>