From: Nat Pryce <nat.pryce@...13media.com>
Date: 2001-10-02T07:12:02+09:00
Subject: [ruby-talk:21893] Re: Let's work on Windows support

My opinion: Ruby needs both cross platform abstractions and access to
platform-specific APIs.  The cross platform abstractions could be
implemented in terms of low level OS APIs, perhaps even in pure Ruby.

This "two-tiered" approach would support both of it's application areas --
system automation scripts and high level programming language.

For example, the current Socket APIs require Ruby scripts to be hard wired
with knowledge about the OS.  Higher level abstractions would improve the
portability of Ruby programs that use sockets in more than a basic, naive
manner (e.g. control the send and receive buffers, TCP Nagle algorithm,
multicast membership etc.).

Cheers,
            Nat.

> Dave Thomas wrote:
>
> > Folks:
> >
> > We currently have a problem with Ruby under Windows. The Cygwin
> > version shipped with the Installshield system is the most fully
> > featured, but at the same time seems to be flaky in some situations
> > (mostly due to Cygwin issues and the normal DLL hell). MinGW seems
> > fairly solid, but there are rumors that it doesn't support all the
> > background process stuff. The native VC++ version has less features,
> > but is easier to integrate with third party DLLs such as Oracle.
> >
> > So, I'm thinking we need to do some stuff. There seems to me to be a
> > short term problem and a long term problem.
> >
> > Short term, we need to work out which of the three available
> > mechanisms to use as the standard for Ruby under Windows. We can then
> > change the Installshield system to use this, and people developing
> > extensions will have something to build against. However, to do this
> > we need to get some hard facts: exactly what isn't available under
> > MinGW. How serious are the Cygwin networking issues? And so on. To do
> > this, I've set up a Wiki page:
> >
> >    http://www.rubygarden.org/ruby?WindowsSupport
> >
> > As it says on the page, this isn't a place for bug reports or "Cygwin
> > sux" messages. As a community, we need to understand the issues in
> > detail and then come to some kind of rational decision we can all live
> > with.
> >
> > Longer term, I suspect we need to be looking at moving away from
> > reliance on third party tools to give us the support we need. I don't
> > know what would be involved. Is it right to try to emulate the Unix
> > process model under Windows? Should there be a Ruby version for
> > Windows with a totally different set of libraries. Should we see if we
> > can work with ActiveState to produce a port? We can discuss all this
> > under http://www.rubygarden.org/ruby?FutureWindows