This is how a shell works. It works by creating processes.
On Unix, you create a process with fork() and execve(). Execve takes a list of arguments, already parsed and tokenized. A shell is free to interpret the command line however it likes to build this, but at the syscall level it is completely unambiguous what the parsed array looks like.
On Windows, you call CreateProcess. This takes the command line as an unparsed string. It is the child process's responsibility to chop it up into argv. This is the source of ambiguity that I'm talking about.
The comment I wrote starting this thread wasn't about command line parsing, it was about pipes, and the need to use a non-space delimiter NULL to pass lists of files that contain spaces.
What you're talking about is related, but different. You're saying that Windows forces an unnecessary join and split (with all the complex rules required to properly parse a quoted string) when using the Windows equivalent of exec(). which is inelegant, but unrelated to what I'm describing above (what I describe above differs because of how newlines and spaces are treated as delimiters (IFS)).
Further, from the testing I did, there is no noticeable impact on my C application which reads from argv- the C runtime seems to handle this transparently.
> Further, from the testing I did, there is no noticeable impact on my C application which reads from argv- the C runtime seems to handle this transparently.
I disagree with your assessment here.
First, the C runtime doesn't have the "part of the system" feel that it does in the Unix world. There is a CRT in the OS, but most programs link to the CRT that ships with visual studio, so it could theoretically change version to version, compiler to compiler.
Apart from that a Win32 application could choose to bypass the CRT's entry point and use WinMain(). Many do. Even if it does use CRT main there is GetCommandLine() to reach the raw command line underneath. Shell32 even has a function CommandLineToArgvW which behaves differently from CRT. Those two are different from parsing done by cmd.exe. There is a lot of ambiguity is my point.