I have some Windows code that uses GetModuleFileName in order to read some additional files at runtime that are expected at certain place relative to the executable.
In Wine, GetModuleFileName doesn't work as intended, and I have trouble to track down the problem. I had to use winemaker's "wrap" option in order to work around initialization problems (C++ code). So the application, "memview.exe.so" is just a small wrapper which loads "memview.dll.so" via "LoadLibrary" and calls the dll's "WinMain".
The startup script (a copy of wineapploader named "memview") determines the application's name to be "memview.exe" and thus executes "wine memview.exe". Under these circumstances, GetModulFileName yields "C:\WINDOWS\SYSTEM\memview.exe", which is not correct. If I alter the winapploader script so that wine gets called with "memview.exe.so" instead, GetModuleFileName yields "Z:\local\builts\phaeaco-20031216\src\memview\memview.exe", which is the correct path (but "memview.exe" doesn't exist).
There is a second application which I built the very same way (i.e. using a small wrapper "phaeaco.exe.so" which loads the actual code contained in the DLL "phaeaco.dll.so"). This application also uses GetModuleFileName; here it always yields "C:\WINDOWS\SYSTEM\phaeaco.dll", no matter whether the application name given to wine by the wineapploader script is "phaeaco.exe" or "phaeaco.exe.so".
This is a confusing picture. Could somebody point out what the expected result of GetModuleFileName is for this scenario (the full path to the dll, I guess) and how it comes about that it yields a path "C:\WINDOWS\SYSTEM..."?
I observed this with Wine-20031118, haven't tested more recent versions.
Ralf