Behaviour of GetModuleFileName

Warren_Baird at Warren_Baird at
Tue May 21 16:10:22 CDT 2002

> Builtin dlls don't have a full path because there is no associated
> file that we could point to (at least as seen from Windows). If this
> breaks your app it can be changed, but I'm not sure it will really fix
> anything. What does the app do with the filename?

To answer your last question first - the code gets the path of the current
library, and then uses that path to find a set of plugins by finding all
libraries matching a certain pattern in the same directory...  A bit hackish,
perhaps, but it works, as long as GetModuleFileName returns a full path...

Isn't there a requirement that the wine libraries be in a directory that is
mappable to a windows path?  I thought I ran into problems when I had forgotten
to add an entry to my wine config to include my wine libraries...  If so, then
there will always be a windows path for each dll...

> You should not need to change the spec file at all. If you need a full
> name you should prefix the name with the windows system directory at
> load time.

Well, the problem is that it's one of our libraries (compiled with winelib) that
is causing the problem - and I have no idea where our libraries have been
installed... I know I could force the users to set up an environment variable or
something to point to the library directory, but this approach is much simpler,
or would be if GetModuleFileName worked as it does on windows...


More information about the wine-devel mailing list