On Fri Oct 24 23:20:48 2025 +0000, Alex Henrie wrote:
but one small difference is that on 32-bit Windows, the function
name reported from SymEnumSymbols is simply GetCurrentThreadId, whereas Wine reports GetCurrentThreadId@0.
I can't repro this
It looks like the @0 appears in 32-bit Wine because [TSymbolloaderthread.LoadDLLSymbols](https://github.com/cheat-engine/cheat-engine/blob/ec45d5f47f92a239ba0bf51ec5...) passes SLMFLAG_NO_SYMBOLS to [SymLoadModuleEx](https://learn.microsoft.com/en-us/windows/win32/api/dbghelp/nf-dbghelp-symlo...). Here's a minimal example which prints "GetCurrentThreadId" on Windows and "KERNEL32_GetCurrentThreadId@0" on current Wine:
// Compile with i686-w64-mingw32-cc and -ldbghelp #include <windows.h> #include <dbghelp.h> #include <shlwapi.h> #include <stdio.h> #ifndef SLMFLAG_NO_SYMBOLS #define SLMFLAG_NO_SYMBOLS 4 #endif BOOL CALLBACK sym_callback(SYMBOL_INFO *info, ULONG size, void *context) { if (StrStrIA(info->Name, "GetCurrentThreadId")) printf("%s\n", info->Name); return TRUE; } int main(void) { ULONG64 base; SymInitialize(GetCurrentProcess(), NULL, FALSE); base = SymLoadModuleEx(GetCurrentProcess(), NULL, "C:\\windows\\system32\\kernel32.dll", NULL, 0, 0, NULL, SLMFLAG_NO_SYMBOLS); SymEnumSymbols(GetCurrentProcess(), base, NULL, sym_callback, NULL); return 0; }(and there's native dbghelp.dll bundled with the cheat-engine, so
which dbghelp is used ? wine's or the bundled) Cheat Engine is definitely using Wine's when running on Wine.
The more important factor appears to be the presence of DWARF debug symbols in my kernel32.dll. If I strip those out, the above test program prints "GetCurrentThreadId" as expected whether compiled as 32-bit or 64-bit.
It seems reasonable to expect debug builds of Wine to work equally well as non-debug builds. Is there any way to fix this bug without making the function's original name be exactly what it should be?