Patch: Win32 Process Implementation

[Ranjit Mathew]

> Here is a patch to Ranjit's Win32 process implementation which
> corrects the fact that both the executable path and its arguments
> need to be quoted if they contain embedded spaces. The patch

IMO, your patch is partly correct (in putting quotes around
cmdArray arguments) - the other "effects" can equally well be
explained in a different manner, not needing any changes to
GCJ per se.

[Please note that the following is based purely on empirical
evidence experimenting with Windows and the JDK.]

Sun's JDK (according to the JDK 1.4.1 docs) treats
cmdArray merely as the tokens of the command line and (as it
turns out) quotes the individual tokens before concatenating
them together to form the command line that is passed to the
Win32 CreateProcess( ) function.

The rest can be explained by the behaviour of CreateProcess( )
as well as the way the command line is parsed by Win32:

http://msdn.microsoft.com/library/en-us/dllproc/base/createprocess.asp

The Windows command line parser uses spaces as delimiters and
quotes to group words separated by spaces into a single 
token - it strips the quotes from the tokens before doing anything
with them. In particular, note that something like 
"foo "bar"snafu wombat" is still treated as a single token.

Runtime.exec( "foo bar\\snafu") seems to work because of the
way Windows tries to look for the executable to execute (refer
to the CreateProcess( ) documentation above) - it breaks if
you also have a program named "foo.exe" in the current folder.

In short, I think if you merely add quotes to the individual
elements of cmdArray before concatenating them to form the
command line, it should still behave quite like the JDK.

Now a short digression on patch preparation and format, based 
on my experience and feedback from the GCJ maintainers, 
in response to your questions on this issue in an earlier
message:

Since I do not use a version control system that can easily
give me differences between my version and the "vendor
version" (term as used in CVS), I do the following - 

a. back up the original file in the same folder with an extra
   ".orig" suffix. Ditto for the ChangeLog file for the
   component (libjava, java, etc.)

b. Update the ChangeLog with a new entry describing the change.
   Format is "yyyy-mm-dd  Your Name  <your@email.address>",
   followed by an empty line, followed by *tab indented* lines
   explaining the changes:

   "path/to/file.java (modified function): change details."

c. Use a slightly modified version of my "makepatch.sh" script
   (as given on my GCJ build page) that just finds files with
   an ".orig" extension, runs "diff -u2" on these files and
   their modified versions, concatenates this output to a
   pseudo "Index" and "===..."  pair of lines (stripping ".orig"
   from the file names) per file - I redirect this output to
   a text file. This should be run from the base folder of the
   component (i.e. the one containing the relevant ChangeLog).
   
d. Run "clcleanup" on this file to get the final submittable
   patch. This can be found in:
   
   http://subversions.gnu.org/cgi-bin/viewcvs/cvs-utils/cvs-utils/

e. verify that the patch actually works as expected by running
   it through "patch --dry-run -p0" on an unmodified copy of the
   source tree (within the base folder of the component).

f. submit it using a mailer that doesn't do any tomfoolery(ha!) with
   the spaces/tabs in your message (the way Mozilla Messenger does)
   and hope Tom doesn't chide you for a bad patch format. ;-)

In practice, since I have a bunch of unrelated ".orig" files 
belonging to various patches and experiments, I first copy the
modified and original files to a separate empty folder 
(maintaining the structure) and a dummy ChangeLog file.

The advantage of this format is that Tom can apply the patch
directly from within his mailer after it is approved.

Hope this helps.

Ranjit.