kernel32: Overhaul the handling of argv in set_process_name().

[Sebastian Lackner]

On 13.07.2016 20:20, Ken Thomases wrote:
>>> However, setproctitle() is specifically documented as a preferred
>>> alternative to the technique of overwriting the arg strings, so
>>> don't shift the strings if that's available.
>> 
>> Wouldn't it make sense to remove the directory component also in
>> this case, to be consistent? By moving the code to the bottom all
>> functions would be called in the same way.
> 
> Well, the only reason we remove the directory component for the other
> calls is because they only allow limited storage.  I'm not aware of a
> similar limit for setproctitle().
> 
> Also, setproctitle() is theoretically more similar to the shifting of
> the argument strings than to setprogname() or prctl(PR_SET_NAME).
> And we don't make any attempt to remove the directory component for
> the string shifting.  (I.e. "ps" will show the full command line,
> potentially including Windows-style .exe path.)

Well, its still very different compared to shifting because all the
following arguments are stripped away. I did some quick tests and it
seems like there are also methods which do preserve the additional
arguments in the "ps" output:

* Either a direct sysctl invocation as done in the setproctitle()
  implementation itself.

* Or, first shift the arguments (both methods work), and then call:
  setproctitle("some string");
  setproctitle(NULL);
  The second call restores the process title as seen by the app.

> 
> Moving the code to the bottom could be done, although it would mean
> two #ifdef HAVE_SETPROCTITLE blocks, one to set shift_strings and the
> other to actually make the call.  The reason is that the shifting has
> to happen before the call to setprogname() because it's documented to
> keep the pointer that's passed in.  We can't pass it (a substring of)
> argv[1] and then shift the strings.

I'm not sure if two #ifdefs is actually that bad, it probably should
depend on the operating system anyway. On systems where it doesn't make
a difference (like FreeBSD, ...) this step can always be safely skipped.

> 
> -Ken
>