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

Sebastian Lackner sebastian at fds-team.de
Wed Jul 13 14:37:38 CDT 2016


On 13.07.2016 21:25, Sebastian Lackner wrote:
> 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.

Actually it looks like we can get the same result just by concatenating
all arguments on the Wine side. The separation of the arguments is lost
in the "ps" output anyway. Depending on how you want to proceed I'll
probably send a patch after you are done with the cleanup. ;)




More information about the wine-devel mailing list