Does the C++ JRuby-launcher affect how JRuby executes commands on Windows via Kernel#system by any chance? Here an example (command prompt session) on Windows where JRuby is removing double quotes from strings before executing them through Kernel#system (which deviates from the behavior on CRuby):

C:\test>file test.rb
test.rb: ASCII text, with CRLF line terminators

C:\test>type test.rb

system "echo \"Hi\""

C:\test>ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x64-mingw32]

C:\test>ruby test.rb
"Hi"

C:\test>jruby -v
jruby 9.0.5.0 (2.2.3) 2016-01-26 7bee00d Java HotSpot(TM) 64-Bit Server VM 25.74-b02 on 1.8.0_74-b02 +jit [Windows 10-amd64]

C:\test>jruby test.rb
Hi

C:\test>echo "Hi"
"Hi"

C:\test>echo Hi
Hi

C:\test>

@preetpalS No but on windows we fall back from a native posix-based launch in some cases (system might be one) to a pure-Java solution. I believe we try and parse quotes and are probably doing it wrong? I think that would be a reasonable new issue to open.

@enebo I opened a new issue (#3788) for JRuby removing double quotes as I believe that this could cause problems on Windows (especially since files and folders with spaces need to be enclosed in double quotes when not escaping spaces individually (especially when using fully qualified names)).

I don't think the problem really lies in JRuby. Rather, the arguments the outermost process gets from the shell (cmd.exe in this case) have already had their quotes stripped, as per console quoting rules. So we can't really tell what the original argument string was.

The best solution for this would be to finally ship both a 32-bit and 64-bit executable and have people install the one that corresponds to their JVM install. We have talked about doing this but I doubt it can make 1.7.27 or potentially any other 1.7.x release (ping @enebo).

A discovery: we may be able to use win32 function GetCommandLine to get the original unadulterated command line. Given that we should be able to pass it along to the child process accurately...I hope!

It appers that GetCommandLine does what it says: it returns the original command line without any shell-processing. However there's a new wrinkle: if there are -Xfoo.bar properties passed to the jruby executable, we'll still need to process them out of the original command line. That means we'll have to deal with re-quoting, etc.

It still seems to me that the best option would be to ship both 32 and 64-bit binaries and have some install process (or user step) copy the right one to jruby.exe.