What does this mean? What Win32 support issues, apart from fork(), are there?
Gavin
PS. Thanks for the roundtable notes, Paul. Editing these into a flowing,
readable interview would create a useful document, IMO.
–
Gavin Sinclair Software Engineer
Sydney, Australia Soyabean Software Pty Ltd
Gavin Sinclair wrote:
What does this mean? What Win32 support issues, apart from fork(), are there?
I would only answer that, if you don’t get any specific answers there
probably are no Win32 support issues 
It has always been a little curious to me that people consider the lack
of fork() – a Unix-specific system call – to be a “bug” in the Win32
version of Ruby. I wonder if those people consider the fact that Ruby’s
Win32API module doesn’t work under Linux a bug?
[snipped]
PS. Thanks for the roundtable notes, Paul. Editing these into a
flowing, readable interview would create a useful document, IMO.
I’ve been monitoring the responses to my original post, and after a few
more days I’m going to collect all the corrections, apply them to the
original document, and submit the entire thing to lwn@lwn.net. I’m also
planning on putting together a HTML version with links to related
information. Is there somewhere else you think I should submit the
result?
–
Gavin Sinclair Software Engineer
Sydney, Australia Soyabean Software Pty Ltd
–
Paul Duncan pabs@pablotron.org pabs in #gah (OPN IRC)
http://www.pablotron.org/ OpenPGP Key ID: 0x82C29562
I don’t think its ‘fork’ the command, but fork-like behavior. Its weird
that on win32 you can use win32ole to start and drive any COM/OLE
component (word, IE, excel) but you cannot start another command-line
executable and drive its behavior (through stdin/out/err). This would
be enabled by open3/popen3 (which under unix is implemented via fork.
-rich
-----Original Message-----
From: Lyle Johnson [mailto:lyle@users.sourceforge.net]
Sent: Tuesday, November 05, 2002 12:23 PM
To: ruby-talk ML
Subject: Re: Win32 support issuesGavin Sinclair wrote:
What does this mean? What Win32 support issues, apart from fork(),
are there?I would only answer that, if you don’t get any specific answers there
probably are no Win32 support issuesIt has always been a little curious to me that people
consider the lack
of fork() – a Unix-specific system call – to be a “bug” in
the Win32
version of Ruby. I wonder if those people consider the fact
that Ruby’s
Win32API module doesn’t work under Linux a bug?
Gavin Sinclair wrote:
What does this mean? What Win32 support issues, apart from fork(), are
there?I would only answer that, if you don’t get any specific answers there
probably are no Win32 support issuesIt has always been a little curious to me that people consider the lack
of fork() – a Unix-specific system call – to be a “bug” in the Win32
version of Ruby. I wonder if those people consider the fact that Ruby’s
Win32API module doesn’t work under Linux a bug?
Point taken. I guess I’d say that so much of Unix
was stolen for Windows (badly) that fork() should
have been stolen also.
Actually, I only think of it as an inconvenience,
not a bug. And it’s because I spent two years
using the Cygwin version (not installing Cygwin
itself, just the DLL) and I could do fork() and
popen3() just fine. I only lost it when we went
native. (And I’m not complaining – I gather
there were good reasons for that, but it was
mostly a step backward for me.)
And DOS got its drive names from CP/M. Can you
imagine how much less painful DOS would have
been with mount points?
But the good thing about minimal support for
Ruby on Windows is that it’s driving me more
and more into the Linux camp. 
Hal
----- Original Message -----
From: “Lyle Johnson” lyle@users.sourceforge.net
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, November 05, 2002 11:22 AM
Subject: Re: Win32 support issues
I’ve been monitoring the responses to my original post, and after a few
more days I’m going to collect all the corrections, apply them to the
original document, and submit the entire thing to lwn@lwn.net. I’m also
planning on putting together a HTML version with links to related
information. Is there somewhere else you think I should submit the
result?
Paul Duncan pabs@pablotron.org pabs in #gah (OPN IRC)
I guess on the Wiki, or wherever else the conference-related material gathers.
It would be nice to keep all that material in one place - even though people
may maintain different things on their own different web pages.
Is anyone leading the charge for post-conference-reportage-consolidation?
Gavin
I think it is about portability. If you use a specific Windows API you are
not likely to run your programm on UNIX. On the other hand the concept of
fork is common in many operating systems.
As for me I have problems with nonblocking I/O in Win32. Consider this:
r, w = IO.pipe
select([r], nil, nil, 1) # → nil in UNIX, [r] in Windows
The result is different in UNIX and Windows (although select works fine in
other cases in Windows).
Dalibor Sramek
On Wed, Nov 06, 2002 at 02:22:45AM +0900, Lyle Johnson wrote:
It has always been a little curious to me that people consider the lack
of fork() – a Unix-specific system call – to be a “bug” in the Win32
version of Ruby. I wonder if those people consider the fact that Ruby’s
Win32API module doesn’t work under Linux a bug?
–
Dalibor Sramek “In the eyes of cats, all things belong to cats.”
dali@insula.cz
Rich Kilmer wrote:
I don’t think its ‘fork’ the command, but fork-like behavior. Its weird
that on win32 you can use win32ole to start and drive any COM/OLE
component (word, IE, excel) but you cannot start another command-line
executable and drive its behavior (through stdin/out/err). This would
be enabled by open3/popen3 (which under unix is implemented via fork).
My understanding was that the main difference between fork() and the
Win32 function CreateProcess() is that fork() makes a copy of the entire
process image, whereas CreateProcess() does not. Are there some other
significant differences that you’re seeing?
Dalibor Sramek wrote:
I think it is about portability. If you use a specific Windows API you are
not likely to run your program on UNIX.
I agree of course. My point was that it is just as absurd to expect
Win32API calls to work under Linux as it is to expect fork() to work
under Windows.
On the other hand the concept of fork is common in many operating systems.
OK, I admittedly am only familiar with Unix and Windows operating systems.
As for me I have problems with nonblocking I/O in Win32. Consider this:
Non-blocking I/O is certainly available in the Windows operating system;
I seem to recall that their terminology for it is “overlapped” I/O, but
that’s a side issue. But just because it’s not implemented in the same
way that it is under Linux/Unix doesn’t make it “wrong”, any more than
the fact that CreateProcess() under Win32 is “wrong” but fork() under
Linux is “right”.
That is my understanding as well and it is this copying of the process
image that win32 does not have (as far as I know). This should not
preclude starting another process and aquiring pipes to the
stdin/out/err, which would serve the FreeRIDE project’s needs (and
likely many others). This is what I think popen3 should do under win32.
-rich
-----Original Message-----
From: Lyle Johnson [mailto:lyle@users.sourceforge.net]
Sent: Tuesday, November 05, 2002 4:44 PM
To: ruby-talk ML
Subject: Re: Win32 support issuesRich Kilmer wrote:
I don’t think its ‘fork’ the command, but fork-like behavior. Its
weird that on win32 you can use win32ole to start and drive any
COM/OLE component (word, IE, excel) but you cannot start another
command-line executable and drive its behavior (through
stdin/out/err). This would be enabled by open3/popen3 (which under
unix is implemented via fork).My understanding was that the main difference between fork() and the
Win32 function CreateProcess() is that fork() makes a copy of
the entire
process image, whereas CreateProcess() does not. Are there some other
significant differences that you’re seeing?
I don’t think it’s fork() that is needed (since almost anything that can
be done with fork() can be done with Threads), but fork/exec. That’s
what CreateProcess does (and a bit more). The fact that fork makes a
copy of the process image isn’t really important, since the process
image gets overwritten when exec() is called. What’s more important is
the fact that file descriptors get duplicated in the child process;
there’s sure to be someone out there who relies on that behavior.
Paul
On Wed, Nov 06, 2002 at 06:43:34AM +0900, Lyle Johnson wrote:
Rich Kilmer wrote:
I don’t think its ‘fork’ the command, but fork-like behavior. Its weird
that on win32 you can use win32ole to start and drive any COM/OLE
component (word, IE, excel) but you cannot start another command-line
executable and drive its behavior (through stdin/out/err). This would
be enabled by open3/popen3 (which under unix is implemented via fork).My understanding was that the main difference between fork() and the
Win32 function CreateProcess() is that fork() makes a copy of the entire
process image, whereas CreateProcess() does not. Are there some other
significant differences that you’re seeing?
Hi,
As for me I have problems with nonblocking I/O in Win32. Consider this:
Another problem due to select(), thread cannot switch while
console input.
STDOUT.flush = true
Thread.start {loop {print “.”; sleep 1}}
p gets
This code continues printing dots until ENTER will be hit under
UNIX or Cygwin, but stops with mswin32/mingw32/bccwin32 version.
Non-blocking I/O is certainly available in the Windows operating system;
I seem to recall that their terminology for it is “overlapped” I/O, but
that’s a side issue. But just because it’s not implemented in the same
way that it is under Linux/Unix doesn’t make it “wrong”, any more than
the fact that CreateProcess() under Win32 is “wrong” but fork() under
Linux is “right”.
Overlapped I/O works only for serial/parallel port actually.
I’d considered about use of it, but abandoned.
At Thu, 7 Nov 2002 00:25:14 +0900, Lyle Johnson wrote:
–
Nobu Nakada
Rich Kilmer wrote:
That is my understanding as well and it is this copying of the process
image that win32 does not have (as far as I know). This should not
preclude starting another process and aquiring pipes to the
stdin/out/err, which would serve the FreeRIDE project’s needs (and
likely many others). This is what I think popen3 should do under win32.
My bad; I thought you were implying that since Win32 doesn’t have a
fork() function that there’s no way to get the behavior that you need,
and that’s why I brought up CreateProces(). Now that I go back and read
your original post, I see that you were specifically talking about
Ruby’s implementation of fork (i.e. Kernel#fork) on Windows, which
doesn’t expose the specific functionality you need (even though we know
it’s available down there somewhere in the OS).
Paul Brannan wrote:
I don’t think it’s fork() that is needed (since almost anything that can
be done with fork() can be done with Threads), but fork/exec. That’s
what CreateProcess does (and a bit more). The fact that fork makes a
copy of the process image isn’t really important, since the process
image gets overwritten when exec() is called. What’s more important is
the fact that file descriptors get duplicated in the child process;
there’s sure to be someone out there who relies on that behavior.
Yup. I think that’s what the fifth argument to CreateProcess (the
“bInheritHandles” argument) ensures – in combination with some of the
other security-related arguments to that function.