[Bug 5224] Grim Fandango patch Gfupd101.exe doesn't start

http://bugs.winehq.org/show_bug.cgi?id=5224

--- Comment #15 from John Doe   2007-12-27 03:28:56 ---
(In reply to comment #14)
> hi there,
>
> I think I've discovered the reason for this bug, I ran into it when attempting
> to run another file from lucasarts ftp server.
>
> ftp://ftp.lucasarts.com/patches/pc/jkupd101.exe which also manifests undefined
> behavior shortly after calling GetCommandLineA.
>
> So, after becoming reacquainted with some assembly, I found out what was going
> on... there's a lack of error checking in these programs, they assume that
> there are double quotes in the string returned by GetCommandLineA, eg
> "c:\jkupd101.exe".
>
> This offending function in jkupd101.exe loops endlessly untill it manages to
> write into memory it doesn't have permission to which causes wine to terminate
> it.
>
> 00401868                           L00401868:
>  00401868  8A4C0408                             mov     cl,[esp+eax+08h]
>  0040186C  40                                   inc     eax
>  0040186D  80F922                               cmp     cl,22h
>  00401870  75F6                                 jnz     L00401868
>
> Note the cmp cl, 22h, where 22 is '"'
>
> As for gfupd101.exe, its undefined behavior ends up looping endlessly (as
> previously reported)
>
> I also tested GetCommandLineA on windows:
>
> When a program is invoked by cmd.exe there are no double quotes.
>
> When a program is launched through explorer  GetCommandLineA returns a string
> with double quotes.
>
> eg
> > c:\GetCommandLineA.exe a b c
>
> C:\GetCommandLineA.exe a b c
>
> but when launched through explorer
> "c:\GetCommandLineA.exe" a b c
>
> Does the behavior of wine need change or can be conclude from this that these
> programs were only meant to be launched by Windows's explorer.exe?
>
> Tested using wine-0.9.51 and Windows 2003.
>
> The test executable can be built from this source:
>
> #include <stdio.h>
> #include <windows.h>
> int main(int argc, char *argv[])
> {
>   printf("%s",GetCommandLineA());
>   getchar(); /* wait for input before the window closes */
>   return 0;
> }

After some testing, it would appear that the behavior of explorer.exe is to
always put the name of the executable in double quotes as the lpApplicationName
argument to CreateProcess, regardless of whether or not the argument contains
spaces.

The behavior of CreateProcess with the lpApplicationName argument set to NULL
is to quote the name of the executable if it or the path contains spaces, if
there are no spaces then the name of the executable or path are not quoted.

These patches from LucasArts appear to rely on the "always quoted" behavior
from explorer.exe.

This means that users can workaround these buggy programs by either running
them with a space in the path to the executable or by renaming the executable
to include a space.

This doesn't look like a wine bug after all.

The following was used to test this behavior on Windows 2003.

#include <windows.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
    if (argc < 2)
    {
        return 1;
    }
    STARTUPINFO si; 
    ZeroMemory(&si, sizeof(STARTUPINFO));
    si.cb = sizeof(STARTUPINFO);
    si.lpReserved = NULL;
    si.lpDesktop = NULL;
    si.lpTitle = NULL;
    si.dwFlags = 0;
    si.cbReserved2 = 0;
    si.lpReserved2 = NULL;
    PROCESS_INFORMATION pi; 
    ZeroMemory(&pi, sizeof(PROCESS_INFORMATION));
    CreateProcess(NULL, argv[1], NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi); 
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
    return 0;
}