Hmm, I wonder if this ever worked. I'll poke around a bit, but if it's possible to narrow this down to just a childprocess call, it would speed things up a lot.

Repro script...seems like either childprocess no longer works on JRuby on Windows, or it never did:

gem 'childprocess'
require 'child_process'
cp = ChildProcess.new('notepad.exe')
cp.start # errors

Ok, I think there's two issues here.

The first is that we do not now (and may never have) provide a proper IO#fileno value for any streams on Windows. In 9k, the logic for getting the Windows "handle" instead of the FD seems to be missing. It may have been removed during 9k work. I have not checked 1.7.

This alone might not be enough of a fix, however, and based on how many places in our code expect fd to be an int (as on Unix) rather than a long (as in a Windows handle) I suspect something else regressed to cause childprocess to stop working.

cc @jarib

The logic in childprocess for getting a proper Windows handle on JRuby does not seem to work right. Given an IO, it digs out the java.nio.channels.Channel and then tries the following (in window_handle_for):

• call #fileno on the original object. This ends up being the fallback value, which on JRuby is -1.
• call getFDVal on the channel to get its FileDescriptor. However, this method is not visible when it is defined at all, so calling it normally from Ruby does not work.

The error that results is due to -1 bubbling through into a get_osfhandle (an FFI win32/posix bridge method I believe). If we fix the logic for getting the fileno/handle, the rest may start working properly again.

I will try a hack to get fileno to return the Windows handle and see if that gets us farther.

Right - I basically gave up on this issue because I couldn't find a way to get the handle on Windows. If you can do it I'd be grateful.

Sorry, I guess I never saw that issue even though you tagged me :-(

So am I getting that the FFI-based version has never worked on JRuby?

At least not with IO.pipe IIRC. It's been a while since I looked into this.

Ok, I think I figured out what broke and fixed it in 9k.

In JRuby 9k, we rewrote a lot of IO stuff, and in the process I believe I broke the "real" file descriptors for stdio channels. When we can use native IO, as on UNIX, it works fine; we have 0, 1, 2 as expected. However on Windows, where we can't (or are not yet) using native IO, we used to unwrap the given JDK streams until we found the FileChannel inside them, and then get the real fileno via reflection. I modified the code to always attempt to unwrap these channels, which appears to make childprocess work correctly (at least for the small example case I came up with).

@jarib Please give JRuby master a try with childprocess and work with me to fix any remaining issues.

@Chuckv Please confirm with JRuby master that things are working better for your case :-)

Is this only fixed in 9 or is it fixed in 1.7 also?

@Chuckv I only fixed it in 9. It may be possible to fix it in 1.7 but I did not investigate that. You need it in 1.7.x, I'm guessing?

@Chuckv I just tested this with JRuby 1.7 HEAD and my short script worked ok. I tried to reproduce using your steps, and got the following error:

irb(main):002:0> b = Watir::Browser.new :phantomJS
ArgumentError: unknown driver: :phantomJS
        from C:/Users/headius/jruby17/lib/ruby/gems/shared/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver/common/driver.rb:49:in `for'
        from C:/Users/headius/jruby17/lib/ruby/gems/shared/gems/selenium-webdriver-2.44.0/lib/selenium/webdriver.rb:67:in `for'
        from C:/Users/headius/jruby17/lib/ruby/gems/shared/gems/watir-webdriver-0.6.11/lib/watir-webdriver/browser.rb:46:in `initialize'

Ok, nevermind...it's :phantomjs not :phantomJS, and I was able to reproduce under 1.7. It looks like it may be a similar issue, but caused instead by us reporting typical stdio descriptors rather than actual stdio descriptors (e.g. $stdin.fileno was 3 under the fixed 9k but is 0 under 1.7 HEAD).

Original reported repro still fails under 9k. Continuing investigation.

I don't have access to a Windows machine to test this at the moment, but if you have suggestions for better approaches childprocess could use to do this, I'm of course happy to make the necessary changes.

Jari, you can download VM images from MS for most combinations of Platform, WinOS, IEversion from microsoft at: https://www.modern.ie/en-us/virtualization-tools#downloads

Or if you need something that will not eventually expire, I might have a spare WinXP and or Win7 hanging around that I could donate your way. Drop me an emailwith your address. Least Ican doafter all you have done for Watir, Webdriver, etc

Ok, I've run into a snag. Streams created by the JDK on Windows do not appear to have filenos attached to them...only handles.

This is not to say that file descriptors aren't being used... doing a native read from fileno 0 works properly. But the streams we get back from the JVM do not have a fileno inside them, as @jarib's code was attempting to locate. They only appear to populate handle inside the JDK FileDescriptor class.

This may mean it's not possible for us to get the proper fileno for streams not created via native APIs (which is all streams on Windows right now). We could provide the handle, but probably not the fileno.

I'm trying to determine if MRI uses file descriptor APIs (_open, _read, etc) or if it uses the HANDLE APIs like _open_osfhandle to make file descriptors from them.

Well I have a fix to report 0, 1, 2 for the stdio streams, but that's not going to help this issue. The stream that's failing in the original example is likely the pipe stream, and on JDK that too appears to have only handle and no fileno.

I think we're going to have to punt this one...the only way I could fix this to work with childprocess's logic would be to switch ALL IO logic in JRuby to use the native posix calls rather than the JDK's streams, so we actually get fileno and not just handle.

It should be possible, however, to fix this in childprocess; I can work with @jarib to dig out the handle correctly on JRuby/JVM.

I have some interesting news.

It seems that with all my fixes in place plus a modification to how we handle the "nul:" device, @Chuckv's original example works correctly on JRuby 9k.

The stream I see failing without latest fix is one opened by phantomjs to the null device, nul: on Windows. JRuby has since 2008 special-cased /dev/null and nul: to be a bogus "NullChannel" that does not have a file descriptor or handle or anything. By removing that logic and allowing "nul:" to actually be a real stream, the win32 handle can be dug out just fine.

I'm going to explore what else this would break, but it seems like an ok change. We probably would not want to backport this to 1.7.x unless we can prove that going back to a real FileChannel versus NullChannel would not cause any unexpected consequences.

With the fixes I've landed on the test-windows-9k branch, the original example appears to work correctly. I'm not sure this is a fix we can make in the 1.7.x timeframe, but we can discuss that.

I still have work to do to make these changes green on *nix, but I'm going to close this and work on that separately.

The fixes have landed on master after some additional tweaks.