Behaviour of GetModuleFileName

[Warren_Baird at cimmetry.com]

> 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...

Warren