load_dll problem

[Dimitrie O. Paun]

Folks,

I am trying to run some Winelib apps built with winegcc, and
they don't work. winegcc/winewrap do the wrapper idea to avoid
initialization problems: basically the main app is built as a
.dll which is loaded with LoadLibrary by a small loader. Well,
this DLL is not found, and the app doesn't load.

I think the problem is in load_dll(), in dlls/ntdll/loader.c
line 887:

if (!libdir || allocated_libdir)
        found = SearchPathA(NULL, libname, ".dll", MAX_PATH, filename, NULL);
    else
        found = DIR_SearchAlternatePath(libdir, libname, ".dll", MAX_PATH, filename, NULL);

As SearchPathA doesn't seem to know that it also needs to
look for the .so version of the DLL.

Here is what happens:

1. Directory contents (simplified)

[dimi@dimi dialogs]$ ls
CVS          dialogs.def     dialogs.h      dialogs.pro
descrip.mms  dialogs.dll.so  dialogs.ico    dialogs.rc
dialogs      dialogs.dsp     dialogsM5.xml  dialogs.rcO
dialogs.cpp  dialogs.exe.so  dialogs.o      dialogs_resources.o

'dialogs' is a small bash script which loads 'dialogs.exe.so' which
does a simple LoadLibrary('dialogs.dll') to load 'dialogs.dll.so'
which is the actual application.

2. Here is the relevant part of:
    ./dialogs --debugmsg +dosfs,+file,+module,+loaddll
   with a 'grep -v trace:dosfs:DOSFS_ReadDir' for brevity.

trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000
trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000
trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000
trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000
trace:module:GetModuleFileNameW L"F:\dev\wine\wxWindows\samples\dialogs\dialogs.exe"
trace:dosfs:DOSFS_GetFullName L"F:\dev\wine\wxWindows\samples\dialogs\dialogs.dll" (last=1)
trace:dosfs:DOSFS_FindUnixName /home/dimi,L"dev\wine\wxWindows\samples\dialogs\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dev\wine\wxWindows\samples\dialogs\dialogs.dll", 0x408a1af0)
trace:dosfs:DOSFS_OpenDir "/home/dimi"
trace:dosfs:DOSFS_FindUnixName (/home/dimi,L"dev\wine\wxWindows\samples\dialogs\dialogs.dll") -> L"dev" (L"DEV")
trace:dosfs:DOSFS_FindUnixName /home/dimi/dev,L"wine\wxWindows\samples\dialogs\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"wine\wxWindows\samples\dialogs\dialogs.dll", 0x408a1af0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/dev"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev,L"wine\wxWindows\samples\dialogs\dialogs.dll") -> L"wine" (L"WINE")
trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine,L"wxWindows\samples\dialogs\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"wxWindows\samples\dialogs\dialogs.dll", 0x408a1af0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine,L"wxWindows\samples\dialogs\dialogs.dll") -> L"wxWindows" (L"WXWI~MP0")
trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows,L"samples\dialogs\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"samples\dialogs\dialogs.dll", 0x408a1af0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine/wxWindows,L"samples\dialogs\dialogs.dll") -> L"samples" (L"SAMPLES")
trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples,L"dialogs\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs\dialogs.dll", 0x408a1af0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine/wxWindows/samples,L"dialogs\dialogs.dll") -> L"dialogs" (L"DIALOGS")
trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples/dialogs,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1af0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples/dialogs"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/dev/wine/wxWindows/samples/dialogs'
trace:dosfs:DOSFS_GetFullName L"dialogs.dll" (last=1)
trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples/dialogs,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1da8)
trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples/dialogs"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/dev/wine/wxWindows/samples/dialogs'
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1dd0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System'
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1dd0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows'
trace:module:GetModuleFileNameW L"F:\dev\wine\wxWindows\samples\dialogs\dialogs.exe"
trace:dosfs:DOSFS_GetFullName L"c:\windows\dialogs.dll" (last=1)
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"windows\dialogs.dll", 0x408a1d44)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\dialogs.dll") -> L"Windows" (L"WINDOWS")
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows'
trace:dosfs:DOSFS_GetFullName L"c:\windows\system\dialogs.dll" (last=1)
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\system\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"windows\system\dialogs.dll", 0x408a1d44)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\system\dialogs.dll") -> L"Windows" (L"WINDOWS")
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"system\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"system\dialogs.dll", 0x408a1d44)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"system\dialogs.dll") -> L"System" (L"SYSTEM")
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System'
trace:dosfs:DOSFS_GetFullName L"e:\\dialogs.dll" (last=1)
trace:dosfs:DOSFS_FindUnixName /tmp,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44)
trace:dosfs:DOSFS_OpenDir "/tmp"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/tmp'
trace:dosfs:DOSFS_GetFullName L"e:\test\dialogs.dll" (last=1)
trace:dosfs:DOSFS_FindUnixName /tmp,L"test\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"test\dialogs.dll", 0x408a1d44)
trace:dosfs:DOSFS_OpenDir "/tmp"
warn:dosfs:DOSFS_FindUnixName L"test\dialogs.dll" not found in '/tmp'
trace:dosfs:DOSFS_GetFullName L"f:\\dialogs.dll" (last=1)
trace:dosfs:DOSFS_FindUnixName /home/dimi,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44)
trace:dosfs:DOSFS_OpenDir "/home/dimi"
trace:dosfs:DOSFS_OpenDir "/home/dimi"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi'
trace:module:MODULE_GetLoadOrder looking for C:\WINDOWS\SYSTEM\dialogs.dll
trace:module:GetModuleFileNameW L"F:\dev\wine\wxWindows\samples\dialogs\dialogs.exe"
trace:module:open_app_key searching 'dialogs' in AppDefaults\dialogs.exe\DllOverrides
trace:module:MODULE_GetLoadOrder got standard wildcard "b,n" for "dialogs.dll"
trace:module:load_dll Trying built-in 'C:\WINDOWS\SYSTEM\dialogs.dll'
warn:module:BUILTIN32_dlopen cannot open .so lib for builtin dialogs.dll: /usr/local/lib/wine/dialogs.dll.so: cannot open shared object file: No such file or directory
trace:module:load_dll Trying native dll 'C:\WINDOWS\SYSTEM\dialogs.dll'
trace:file:CreateFileW L"C:\WINDOWS\SYSTEM\dialogs.dll" GENERIC_READ FILE_SHARE_READ OPEN_EXISTING  attributes 0x0
trace:dosfs:DOSFS_GetFullName L"C:\WINDOWS\SYSTEM\dialogs.dll" (last=1)
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"WINDOWS\SYSTEM\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"WINDOWS\SYSTEM\dialogs.dll", 0x408a1fe0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"WINDOWS\SYSTEM\dialogs.dll") -> L"Windows" (L"WINDOWS")
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"SYSTEM\dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"SYSTEM\dialogs.dll", 0x408a1fe0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows"
trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"SYSTEM\dialogs.dll") -> L"System" (L"SYSTEM")
trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll"
trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1fe0)
trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System"
warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System'
warn:file:CreateFileW Unable to get full filename from L"C:\WINDOWS\SYSTEM\dialogs.dll" (GLE 2)
warn:module:load_dll Failed to load module 'C:\WINDOWS\SYSTEM\dialogs.dll'; status=-1073741809
trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000

[Eric Pouech]

Dimitrie O. Paun wrote:
> Folks,
>
> I am trying to run some Winelib apps built with winegcc, and
> they don't work. winegcc/winewrap do the wrapper idea to avoid
> initialization problems: basically the main app is built as a
> .dll which is loaded with LoadLibrary by a small loader. Well,
> this DLL is not found, and the app doesn't load.
>
> I think the problem is in load_dll(), in dlls/ntdll/loader.c

AFAIR, builtin DLLs are only loaded from LD_LIBRARY_PATH (not any Win32 
related stuff, like win32 system dir...)
adding your dialogs dir to LD_LIBRARY_PATH should do (your shell would 
do I think)
(look what tools/wrapper does ;-)

A+

[Eric Pouech]

> AFAIR, builtin DLLs are only loaded from LD_LIBRARY_PATH (not any Win32 
> related stuff, like win32 system dir...)
> adding your dialogs dir to LD_LIBRARY_PATH should do (your shell would 
> do I think)
> (look what tools/wrapper does ;-)
>
> A+

in fact, it's not LD_LIBRARY_PATH but WINEDLLPATH which is used 
(LD_LIBRARY is only used for the pure .so libraries, not our builtint DLLs)

A+

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> I am trying to run some Winelib apps built with winegcc, and
> they don't work. winegcc/winewrap do the wrapper idea to avoid
> initialization problems: basically the main app is built as a
> .dll which is loaded with LoadLibrary by a small loader. Well,
> this DLL is not found, and the app doesn't load.

You need to put it in WINEDLLPATH. You could also specify the full
path, though this may only work for .exe.so for the moment, I haven't
verified that. But I think it would be better to get rid of the
wrapper dll concept, and fix the constructor issues properly.

[Dimitrie O. Paun]

On 14 May 2003, Alexandre Julliard wrote:
> You need to put it in WINEDLLPATH. You could also specify the full
> path, though this may only work for .exe.so for the moment, I haven't
> verified that. But I think it would be better to get rid of the
> wrapper dll concept, and fix the constructor issues properly.

You don't have to convince me -- I've been arguing for that 
for a long time :)

But the issue is still there. What if the app has a app.dll
DLL that is not a wrapper? Anyway, the fix would probably be
to simply have . in WINEDLLPATH, no?

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> But the issue is still there. What if the app has a app.dll
> DLL that is not a wrapper? Anyway, the fix would probably be
> to simply have . in WINEDLLPATH, no?

No, '.' is wrong. The correct path is "wherever the application puts
its dlls". Obviously there's no general solution for that, it's up to
the app to set things up properly.

[Dimitrie O. Paun]

On 14 May 2003, Alexandre Julliard wrote:
> No, '.' is wrong. The correct path is "wherever the application puts
> its dlls". Obviously there's no general solution for that, it's up to
> the app to set things up properly.

Right -- '.' is obviously not the right answer. Regardless, we need
to save this problem, I can't run Winelib apps no more.

I see two possibilities:
  1. Look in the same dir as the .exe.so for the .dll.so
  2. Fix the constructor thing properly, and avoid the wrapper

For 2, I'm not even sure what we need to do. You promissed some liker
magic and eblow greese some time ago, but other than that...

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> I see two possibilities:
> - Look in the same dir as the .exe.so for the .dll.so
> - Fix the constructor thing properly, and avoid the wrapper
>
> For 2, I'm not even sure what we need to do. You promissed some liker
> magic and eblow greese some time ago, but other than that...

I think the problems that the wrapper was supposed to solve are solved
by using a .exe.so already. There may be some remaining issues with
the constructor order but you will have these with the wrapper too. So
I'd say let's just kill it and see what happens.

[Dimitrie O. Paun]

On May 14, 2003 06:11 pm, Alexandre Julliard wrote:
> I think the problems that the wrapper was supposed to solve are solved
> by using a .exe.so already. There may be some remaining issues with
> the constructor order but you will have these with the wrapper too. So
> I'd say let's just kill it and see what happens.

None of the C++ stuff I have (Visual-MinGW, and wxWindows samples) seem
to work without the wrapper. Last time we talked about this you were
saying that the big problem where the variables which we could not intercept,
and thus were linked at the Unix level by ld instead of us. How was that
problem solved, my understanding was that it requires PE support in ld.

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> None of the C++ stuff I have (Visual-MinGW, and wxWindows samples) seem
> to work without the wrapper. Last time we talked about this you were
> saying that the big problem where the variables which we could not intercept,
> and thus were linked at the Unix level by ld instead of us. How was that
> problem solved, my understanding was that it requires PE support in ld.

Ah right, I forgot about that one. Yes this is a pain to solve; it
will probably require the loader to go muck about in the ELF GOT.

[Dimitrie O. Paun]

On May 19, 2003 01:21 pm, Alexandre Julliard wrote:
> Ah right, I forgot about that one. Yes this is a pain to solve; it
> will probably require the loader to go muck about in the ELF GOT.

OK, which means... :) Do we have a solution for this around the
corner, or we have to find another workaround for the Winelib apps?

[Mike Hearn]

Well, at some point in the next year or two (probably <2 years) I might
well end up doing some pretty extensive hacking on ld and the rtld
(dynamic linker) to support my other project. The glibc team have said
they want these features but have no concrete plans to add them :(

While I'm there, I suppose I could take some extra time to add any
features Wine might find useful at that level - from what I've been told
it seems the lead in time to being able to usefully hack on the glibc
ELF interpreter is high, so put in your requests now.

On Tue, 2003-05-20 at 06:44, Dimitrie O. Paun wrote:
> On May 19, 2003 01:21 pm, Alexandre Julliard wrote:
> > Ah right, I forgot about that one. Yes this is a pain to solve; it
> > will probably require the loader to go muck about in the ELF GOT.
>
> OK, which means... :) Do we have a solution for this around the
> corner, or we have to find another workaround for the Winelib apps?

[Dimitrie O. Paun]

On May 20, 2003 04:33 am, Mike Hearn wrote:
> While I'm there, I suppose I could take some extra time to add any
> features Wine might find useful at that level - from what I've been told
> it seems the lead in time to being able to usefully hack on the glibc
> ELF interpreter is high, so put in your requests now.

Yes, we should have a working list of this sort of things that we require
from external projects such as gcc/ld/kernel/glibc/etc. Maybe something
to discuss on the IRC meeting, eh? :)

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> On May 19, 2003 01:21 pm, Alexandre Julliard wrote:
> > Ah right, I forgot about that one. Yes this is a pain to solve; it
> > will probably require the loader to go muck about in the ELF GOT.
>
> OK, which means... :) Do we have a solution for this around the
> corner, or we have to find another workaround for the Winelib apps?

It basically means teaching ld.so about the PE format, and/or teaching
our PE loader about the ELF format.  We don't have a solution around
the corner, and we are unlikely to have one any time soon IMO. The
simplest approach is to build the Winelib app in PE format, but of
course that's not ideal...

[Dimitrie O. Paun]

On 20 May 2003, Alexandre Julliard wrote:
> It basically means teaching ld.so about the PE format, and/or teaching
> our PE loader about the ELF format.  We don't have a solution around
> the corner, and we are unlikely to have one any time soon IMO. The
> simplest approach is to build the Winelib app in PE format, but of
> course that's not ideal...

In other words will have to keep the wrapper for some time. That being
said, we'll need to fix somehow the WINEDLLPATH problem, right now the
generated executable simply does not run.

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> In other words will have to keep the wrapper for some time. That being
> said, we'll need to fix somehow the WINEDLLPATH problem, right now the
> generated executable simply does not run.

winewrap is generating a wrapper script already, isn't it?  So you can
simply set WINEDLLPATH in there.

[Dimitrie O. Paun]

On May 20, 2003 01:06 pm, Alexandre Julliard wrote:
> winewrap is generating a wrapper script already, isn't it?  So you can
> simply set WINEDLLPATH in there.

Well, that doesn't work. For one, WINEDLLPATH is honoured only in
libs/wine/loader.c:dlopen_dll(), which is invoked only from:
  -- wine_dll_load_main_exe(): Try to load the .so for the main exe.
  -- wine_dll_load(): Load a builtin dll.

A Winelib app with a wrapper calls LoadLibrary("appname.dll"). This
ends up in ./dlls/ntdll/loader.c:load_dll() which calls
SearchPathA(NULL, "appname", ".dll", MAX_PATH,...) to find the DLL.

Herein lies the problem:
  -- SearchPathA does not know about WINEDLLPATH, it will just look
     for "appname.dll" which obviously does not exist (because we
     have "appname.dll.so"). The trace clearly shows that it will
     look in the right directory for "appname.dll", and it fails to
     find it, so it proceeds to look in the WINDOWS dir. So the
     path is not the problem, but rather the fact that SearchPath
     doesn't know to also look for .so file when searching for a .dll.

-- I've changed the wrapper to LoadLibrary("appname.dll.so"). This
     works a bit better in the sense that now SearchPathA finds the
     file. However, it fails to load because now it tries to load it
     as a native DLL (PE), which is not:

trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine/visual-mingw/bin,L"visual-mingw-wrap.dll.so") -> L"visual-mingw-wrap.dll.so" (L"VISU~Y42.SO")
trace:dosfs:DOSFS_GetFullName returning /home/dimi/dev/wine/visual-mingw/bin/visual-mingw-wrap.dll.so = L"F:\DEV\WINE\VISU~YHA\BIN\VISU~Y42.SO"
trace:dosfs:GetDriveTypeW (L"F:\DEV\WINE\VISU~YHA\BIN\VISU~Y42.SO")
trace:file:CreateFileW returning 0x38
trace:module:PE_LoadImage loading F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so
warn:module:load_dll Loading of native DLL F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so failed (status -1073741595).
warn:module:load_dll Failed to load module 'F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so'; status=-1073741595

Note: I've renamed the wrapped app "<appname>-wrap.dll" to avoid possible
    conflicts with app-supplied DLLs.

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> Herein lies the problem:
>   -- SearchPathA does not know about WINEDLLPATH, it will just look
>      for "appname.dll" which obviously does not exist (because we
>      have "appname.dll.so"). The trace clearly shows that it will
>      look in the right directory for "appname.dll", and it fails to
>      find it, so it proceeds to look in the WINDOWS dir. So the
>      path is not the problem, but rather the fact that SearchPath
>      doesn't know to also look for .so file when searching for a .dll.

That shouldn't matter, it should load the .so even if the
corresponding .dll doesn't exist, as long as the .so is somewhere in
WINEDLLPATH. Is the load order configured correctly?

[Dimitrie O. Paun]

On 23 May 2003, Alexandre Julliard wrote:
> That shouldn't matter, it should load the .so even if the
> corresponding .dll doesn't exist, as long as the .so is somewhere in
> WINEDLLPATH. Is the load order configured correctly?

I'm not sure how all this works, but you probably know better.
The load order is b,n which is the default order. If I understand
this correctly, it means it should first try the dllname.dll.so, 
and if that's not found, it should try dllname.dll.

One thing's for sure. WINEDLLPATH contains the right directory,
but Wine is not looking for the right file in it. And as I
explained, I can't see how this will work (from the cursory
look I took at it).

[Eric Pouech]

> One thing's for sure. WINEDLLPATH contains the right directory,
> but Wine is not looking for the right file in it. And as I
> explained, I can't see how this will work (from the cursory
> look I took at it).

every builtin DLLs, when searched without path, ends up with a name of 
c:\windows<dllname> in wine_dlopen and friends
then this function, removes the path part and looks up into the WINEDLLPATH.

A+

[Mike Hearn]

Hmm, when was this problem last discussed? I'd like to read about it. I
seem to recall something about C++ static initializers, which is one
reason why you need this wrapper thing (to init winelib before the app
starts), but what is this about intercepting variables?

Is the problem with altering the GOT a matter of writing a parser, or
figuring out which entries are variables, or something else?

It seems to me that adding PE support to the rtld would be hard to write
and extremely difficult to actually get merged by the glibc team - of
course you can still alter .interp to use a wine specific linker, but I
think that would get messy dependancy wise (i doubt ld is well insulated
from the rest of the glibc internals). It'd probably be easier to add
ELF support to Wine.

On Tue, 2003-05-20 at 17:24, Alexandre Julliard wrote:
> "Dimitrie O. Paun"  writes:
> > On May 19, 2003 01:21 pm, Alexandre Julliard wrote:
> > > Ah right, I forgot about that one. Yes this is a pain to solve; it
> > > will probably require the loader to go muck about in the ELF GOT.
> >
> > OK, which means... :) Do we have a solution for this around the
> > corner, or we have to find another workaround for the Winelib apps?
>
> It basically means teaching ld.so about the PE format, and/or teaching
> our PE loader about the ELF format.  We don't have a solution around
> the corner, and we are unlikely to have one any time soon IMO. The
> simplest approach is to build the Winelib app in PE format, but of
> course that's not ideal...

[Alexandre Julliard]

Mike Hearn  writes:
> Hmm, when was this problem last discussed? I'd like to read about it. I
> seem to recall something about C++ static initializers, which is one
> reason why you need this wrapper thing (to init winelib before the app
> starts), but what is this about intercepting variables?

The way we link functions is by creating an intermediate jump that we
can resolve ourselves. Obviously this doesn't work for variables,
there's no way to insert an extra indirection, so we would need to
work directly with the ELF tables, or else have the compiler generate
PE indirections for us.
> Is the problem with altering the GOT a matter of writing a parser, or
> figuring out which entries are variables, or something else?

It's a matter of doing the ELF run-time linking ourselves, so that we
can use PE libraries to resolve imports. We may also need something at
link time so that the ELF linker can be tricked in believing the
variables exist. Basically it's a major piece of work, that I doubt
will be done soon, if ever.

Other possibilities include building as PE format, which should work
today, or using ELF linking throughout and giving up on native
libraries, which would still require a bit of work. The latter is
probably the best choice for Winelib, but since it's useless for the
binary emulator it's not really high priority.