Well there is now!
Until recently 95% of the work was done on wine. WineLib was a side effect. Look what happens, if I have a "-wrap" application (C++) I need to place a link to it in WINEDLLPATH to even load. and also to all it's supporting DLLs (I know I have 36 of them). If any one is working on it, built in search should support both explicit Path loading, and executable directory. Same as native, Just that the PATH and system-folder changes to WINEDLLPATH. Once the built-in is found it's PATH should be recorded and later served on requests like GetModuleFileName and others. If no one else is doing it? It is the next thing on my list after all the current changes are submitted.
And while we are at it. What is the wine policy about Built-in DLLs versions. I have encountered problems where setups where complaining about versions been "0.0.0.0" and also some other not high enough versions. Should we make a quick study about Windows versions and serve them as per WinVER reported?
And Alexandre welcome back. I hope you had a good time and a well deserved rest. It was kind of gloomy around here with out you.
Free Life Boaz
Alexandre Julliard wrote:
"Ralf Juengling" juenglin@cse.ogi.edu writes:
But what is the reason for having GetModuleFileName return the system dir for "builtin DLLs"?
Because we don't know the real path, and even if we did there is no guarantee that it is accessible from a Windows drive.
Also, why does it behave differently for the two programs, as I reported in my initial posting; is one of the two cases exhibiting a bug?
Because in one case you used a .exe.so and in the other a .dll.so, they behave slightly differently. It's not really a bug, just a side effect of the fact that you can load a .exe.so by specifying its path explicitly, which you cannot do for builtin dlls. This could be changed, but there hasn't been any real need for that yet.