After reading your post I wondered what my command line parsing code was doing in such a case.
After some tests, it looks to me that cmd.exe
is parsing the command line and separating the executable of its arguments, and then creating the process with a space in the command line. It's not the CRT or CommandLineToArgvW
that is parsing a command line without space.
Also in my tests, if you don't add a space between the arguments then there will be only one arguments /s/q
. So remedybg seems to be doing what is expected. You can see this if you call GetCommandLineW
on the executable you ran in cmd.exe
.
#include <windows.h>
#include <shellapi.h>
int main( int argc, char** argv ) {
__debugbreak( );
LPCWSTR cmd = GetCommandLineW( );
int argcw = 0;
LPCWSTR* argvw = CommandLineToArgvW( cmd, &argcw );
return 0;
}
I think that using /
to specify arguments is a Microsoft convention and there isn't a defined meaning for a /
in arguments, it's just a character in a string. You probably already know about this, but just in case: Parsing C++ Command-Line Arguments
RemedyBG could probably add a way to specify an exact command line, but, assuming it uses CreateProcess
to start the executable, it would need to do what cmd.exe
does (separating the executable and arguments) as it would need to pass the exe in the first arguments of create process, then the full command line in the second argument (trying to pass the full command line without space in the first argument, or the second if the first is null, of CreateProcess
will fail to create the process). And that behavior would not replicates what happens when you run from the command line (or batch file). So it would probably be just confusing.
You could do your tests by creating the process yourself, and adding a __debugbreak( )
in the test process at the start to trigger a breakpoint to let you attach a debugger:
CreateProcessW( L"test.exe", L"test.exe/s/q", 0, 0, 0, 0, 0, L".\\", &startup_information, &process_information );