The documentation for QStringList QCoreApplication::arguments() (Qt) states that:
Usually arguments().at(0) is the
program name, arguments().at(1) is the
first argument, and arguments().last()
is the last argument. See the note
below about Windows.
It further elaborates:
On Windows, […] the arguments() are
constructed from the return value of
GetCommandLine(). As a result of this,
the string given by arguments().at(0)
might not be the program name on
Windows, depending on how the
application was started.
Referring to the last bold part, I am curious about which situation does this applies in. The Qt documentation doesn’t explain it nor does GetCommandLine‘s (WINAPI) documentation.
This can happen when your program is spawned via CreateProcess – have a look at the description for the lpCommandLine parameter. Basically it is up to the program calling CreateProcess to fill in that first parameter, so it can happen that the value isn’t filled in the usual way.
From the link:
“If both lpApplicationName and lpCommandLine are non-NULL, the null-terminated string pointed to by lpApplicationName specifies the module to execute, and the null-terminated string pointed to by lpCommandLine specifies the command line. The new process can use GetCommandLine to retrieve the entire command line. Console processes written in C can use the argc and argv arguments to parse the command line. Because argv[0] is the module name, C programmers generally repeat the module name as the first token in the command line.”
Similarly, this can happen if your program is started from another using the spawn family of functions. There, the documentation states:
“At least one argument, either arg0 or argv[0], must be passed to the child process. By convention, this argument is a copy of the pathname argument. However, a different value will not produce an error.”