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
-
Warren_Baird＠cimmetry.com