QStringList QCoreApplication :: arguments () - in what situation is index 0 not the application path on Windows?

Question

The documentation for QStringList QCoreApplication::arguments() (Qt) states that:

Usually arguments (). at (0) is the name of the program, arguments (). at (1) is the first argument and arguments (). last () is the last argument. See the note below about Windows.

It is further specified:

In Windows, arguments [...] are constructed from the return value of GetCommandLine (). As a result, the string specified by the arguments (). at (0) may not be the name of the program on Windows, depending on how the application was launched.

Referring to the last half-dead part, I wonder in what situation this happens. The Qt documentation does not explain this, and does not run GetCommandLine (WINAPI).

Answer 1

This can happen when your program is created through CreateProcess - see the description of the lpCommandLine parameter. This mainly depends on the program calling CreateProcess to populate this first parameter, so it may happen that the value is not populated in the usual way.

From the link:

"If both lpApplicationName and lpCommandLine are not NULL, the null-terminated string indicated by lpApplicationName is the executable, and the null-terminated string indicated by lpCommandLine is the command line. The new process can use GetCommandLine to get the entire command line Console processes written in C can use the arguments argc and argv to parse the command line. Since argv [0] is the name of the module, C programmers usually repeat the name of the module as the first token in the command line. "

Similarly, this can happen if your program is launched from another using the spawn family of functions. There the documentation reads:

"At least one argument arg0 or argv [0] must be passed to the child process. By convention, this argument is a copy of the pathname argument. However, another value will not result in an error."