[PATCH v2] kernel32: Use setprogname(3) to set the program name if available.

[Ken Thomases]

On Apr 26, 2016, at 3:38 PM, Sebastian Lackner <sebastian at fds-team.de> wrote:
> 
> On 26.04.2016 22:35, Theodore Dubois wrote:
>> I have both a custom wine loader and a hacked version of Wine, so I just reverted the patch.
>> 
>> It would be really nice to have this work for when I’m not using a custom loader. Maybe you could check if argv is in the malloc heap? Or maybe I could somehow indicate when calling wine_init that the argv is malloced?
>> 
>> ~Theodore
>> 
> 
> May I ask why you are not just allocating the argv array in a way compatible to the OS?
> When you have full control in your custom loader, this should be trivial and the easiest
> way to fix it.

Forgive me for reviving an old thread, but how was it determined that allocating all of the strings pointed to by argv as a single buffer is what the OS does?  This does not seem like a portable assumption.

Also, why should set_process_name() shift the strings up within the (supposedly contiguous) string buffer?  For the HAVE_SETPROCTITLE, it doesn't do that.  Prior to Chip's commit, it didn't do that on macOS.  So, Theodore's original question, "Why wouldn’t setprogname(argv[1]) be adequate?", is pretty close.  It should have been, "Why wouldn’t setprogname(argv[1]) followed by shifting the elements of argv up one be adequate?"

I'm not even sure why the string buffer is shifted for Linux.  It looks like it's leftover logic that's no longer relevant (having to do with vdm?).

I'll also note that Chip's commit broke things for the case where none of HAVE_SETPROCTITLE, HAVE_SETPROGNAME, or HAVE_PRCTL is defined.  In that case, nothing shifts the elements of argv up one anymore.  It used to.

-Ken