[Bug 51524] New: szExeFile is different from Windows

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51524

Bug ID: 51524
           Summary: szExeFile is different from Windows
           Product: Wine
           Version: 6.13
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

When calling Process32Next, szExeFile in the returned structure is different
from Windows.

Here is the source code for programs I used to test this:
// app.cpp
// i686-w64-mingw32-gcc app.cpp -o app.file
#include <windows.h>

int main() {
  Sleep(5000);
}

// test.cpp
// i686-w64-mingw32-g++ -static-libstdc++ -static-libgcc test.cpp -o test.exe
#include <cstdio>
#include <windows.h>
#include <tlhelp32.h>

int main() {
  STARTUPINFOW sinfo;
  memset(&sinfo, '\0', sizeof(sinfo));
  sinfo.cb = sizeof(sinfo);
  PROCESS_INFORMATION info = {0};
  wchar_t str[] = L"App.file";
  CreateProcessW(NULL, str, NULL, NULL, FALSE, 0, NULL, NULL, &sinfo, &info);

HANDLE snapshotHandle = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
  LPPROCESSENTRY32 lppe;
  if (Process32First(snapshotHandle, lppe)) {
    while (Process32Next(snapshotHandle, lppe)) {
      if (!_stricmp("App.file", lppe->szExeFile)) {
        printf("%s\n", lppe->szExeFile);
      }
    }
  }
}

Running test.exe with wine I get the following output:
lahvuun@lahvuun ~/git/winebug wine test.exe
App.file

On Windows 10 with powershell and the same pair of binaries I get:
PS D:\app> ./test.exe
app.file

[Bug 51524] szExeFile is different from Windows

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51524

Fabian Maurer  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Fabian Maurer  ---
Just to be sure, it's only about the capitalization, right?

On Win7, it looks like on wine. Is that an actual problem with a program or
just something you noticed?

[Bug 51524] szExeFile is different from Windows

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51524

--- Comment #2 from Ilya Trukhanov  ---
It's a problem with the program called cnconline. It patches the game's memory
at runtime to make it use unofficial multiplayer servers. To find the game it
uses CreateToolhelp32Snapshot and then compares szExeFile to the filename it
expects. The filename in my case is "ra3_1.12.game", but the command line
starts with "RA3_1.12.game".

Wine seems to set szExeFile to "RA3_1.12.game", while on my Windows 10
installation it's "ra3_1.12.game", so cnconline never finds the game under
Wine.

[Bug 51524] szExeFile is different from Windows

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51524

--- Comment #3 from Fabian Maurer  ---
As a workaround, you could rename the game file to have lowercase. does that
make it work?

That sounds like changed behavior in windows... Would you be able to test
whether the program works on Windows 7?

[Bug 51524] szExeFile is different from Windows

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=51524

--- Comment #4 from Ilya Trukhanov  ---
The binary name already is lowercase, but there is a workaround.

I didn't want to explain how cnconline and the game work to avoid unnecessary
information, but maybe this will clear things up a bit.

The way the game works is it has a single .exe launcher and a bunch of binaries
for different game versions: "ra3_1.0.game", "ra3_1.1.game", all the way up to
"ra3_1.12.game". The launcher simply picks one of these binaries (not sure how,
likely the highest version) and runs it with CreateProcessW with
lpApplicationName set to NULL. The command line for starting these binaries
comes from text files. There is, for instance, a file called
"RA3_english_1.12.SkuDef" and its first line is "set-exe Data\RA3_1.12.game".
This is a part of the command line that "ra3_1.12.game" would be started with.

I know this because I disassembled the launcher and found where the call to
CreateProcessW is (eax is lpCommandLine):
Wine-gdb> x /sh $eax
0xcc5a50:      
u"Z:\home\lahvuun\fasthdd\games\Windows\RA3\Data\RA3_1.12.game -config
"Z:\home\lahvuun\fasthdd\games\Windows\RA3\RA3_english_1.12.SkuDef" "

The workaround is to edit the first line of the file to "set-exe
data\ra3_1.12.game":
Wine-gdb> x /sh $eax
0xcc5a50:      
u"Z:\home\lahvuun\fasthdd\games\Windows\RA3\Data\ra3_1.12.game -config
"Z:\home\lahvuun\fasthdd\games\Windows\RA3\RA3_english_1.12.SkuDef" "

As you can see, the binary name in the command line is now lowercase. cnconline
will also successfully find the game and work as expected now.

Of course, this is not needed at least on Windows 10, because there szExeFile
will be "ra3_1.12.game" regardless of how that first line in
"RA3_english_1.12.SkuDef" is capitalized. My *guess* is that Windows sets
szExeFile to the actual file name, while Wine sets it to the first token in
lpCommandLine. I could probably test this with different capitalizations for
both the file name and command line if you want.
> That sounds like changed behavior in windows...

I doubt that. I asked in the cnconline discord server if the program works on
Windows 7 and was told that it does.
> Would you be able to test whether the program works on Windows 7?

My test example actually crashes on Windows 7, not sure why. It will take me a
few days to test if cnconline works on that computer.