Hi,
on Windows, the mechanism to launch a new program is for the parent to
call CreateProcess(). This function accepts, among others parameters, a
lpApplicationName string and a lpCommandLine string. There's a *single*
lpCommandLine that encodes all the arguments to pass to the new program.
The exact encoding of the arguments in the command line is imposed by
how the *new* program parses (decodes) the command line to get its
constituent parts. There are no fixed rules on how this happens. There
are some more or less well documented rules for some runtimes (e.g., the
C/C++ runtime) or for some specific programs (e.g., cmd.exe.,
wscript.exe). In general, however, a program can decode in any way it
deems useful.
Because the encoding is dictated by the target program's decoding, and
because the latter is really arbitrary, there's no safe, universal
procedure to encode a list of string arguments to a single command line
string. It is only when the decoding rules in the target program are
known that encoding in the parent becomes feasible.
Thus, it might be more useful on Windows platforms to avoid the API
points that expose List<String> or String[] for the arguments to the
target program and use the ones that accept a single String, instead.
The client of those API points would then have to deal with the encoding
specific for that program. This is a better match with the underlying OS
mechanism, namely CreateProcess(), which accepts a single, already
encoded string.
In addition, to assist programmers unfamiliar with specific encodings,
widely used specific encoders (e.g., for the C/C++ runtime [1], for
cmd.exe, etc.) can be implemented separately.
Greetings
Raffaello
----
[1]
https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086105.html
