GetModuleFileName mysteries

[Ralf Juengling]

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

-- 
Ralf Juengling <juenglin at cse.ogi.edu>