Am 2015-02-06 12:07, schrieb Nikolay Sivov:
On 06.02.2015 14:02, Patrick Rudolph wrote:
Am 2015-02-06 09:22, schrieb Nikolay Sivov:
On 06.02.2015 11:12, Patrick Rudolph wrote:
Hi guys, I tried WoW as it seems to be in a good shape, but run into same issues. I hope you can clarify. I've got an game that has two executables, 32bit and 64bit. It places a 32bit version of xinput1_3.dll in the same folder on startup. Trying to start the 32bit version works fine, however starting the 64bit version doesn't work. For me it looks like the ntdll load_dll is the fault. It searches for builtin xinput1_3 and finds the 32bit dll in the game folder. It fails to open it (wrong ARCH) and that's it. Instead of trying other directories it tries to load native. Again it opens the first file found in the given path, it's the same file again, it fails to open it and the application terminates.
Why doesn't it check for correct ARCH ? Why doesn't it walk all directories / all path given, instead of just using the first file found ?
What do you mean by that? It doesn't check usual System32 dir for 64 bit dll, is that what you expect?
Why doesn't it check for files in syswow64 ?
Because syswow64 is a directory for 32bit system dlls/exes. So for 64bit process it doesn't make much sense to look for dependencies there.
So system32 contains 64bit libraries and syswow64 32bit libraries... OK. then why doesn't it look into system32 for the correct dll ?
Does Windows 64bits behave the same ?
Does this game work in Windows with same conditions? Or any minimal test case for that matter, like 64bit exe + 32bit dll with appropriate name, is that what you see?
I guess it is working, why should a vendor release a non functional game ? But I cannot test it, as I do not own a Windows.
Maybe you just need 64bit version of xinput then?
I can't place it in the same folder as there's already a 32bit version. Why doesn't it take the 64bit version in system32.
Regards
On 06.02.2015 14:53, Patrick Rudolph wrote:
Am 2015-02-06 12:07, schrieb Nikolay Sivov:
On 06.02.2015 14:02, Patrick Rudolph wrote:
Am 2015-02-06 09:22, schrieb Nikolay Sivov:
On 06.02.2015 11:12, Patrick Rudolph wrote:
Hi guys, I tried WoW as it seems to be in a good shape, but run into same issues. I hope you can clarify. I've got an game that has two executables, 32bit and 64bit. It places a 32bit version of xinput1_3.dll in the same folder on startup. Trying to start the 32bit version works fine, however starting the 64bit version doesn't work. For me it looks like the ntdll load_dll is the fault. It searches for builtin xinput1_3 and finds the 32bit dll in the game folder. It fails to open it (wrong ARCH) and that's it. Instead of trying other directories it tries to load native. Again it opens the first file found in the given path, it's the same file again, it fails to open it and the application terminates.
Why doesn't it check for correct ARCH ? Why doesn't it walk all directories / all path given, instead of just using the first file found ?
What do you mean by that? It doesn't check usual System32 dir for 64 bit dll, is that what you expect?
Why doesn't it check for files in syswow64 ?
Because syswow64 is a directory for 32bit system dlls/exes. So for 64bit process it doesn't make much sense to look for dependencies there.
So system32 contains 64bit libraries and syswow64 32bit libraries... OK. then why doesn't it look into system32 for the correct dll ?
There's no way to tell, as you didn't provide any information.
Does Windows 64bits behave the same ?
Does this game work in Windows with same conditions? Or any minimal test case for that matter, like 64bit exe + 32bit dll with appropriate name, is that what you see?
I guess it is working, why should a vendor release a non functional game ? But I cannot test it, as I do not own a Windows.
Maybe you just need 64bit version of xinput then?
I can't place it in the same folder as there's already a 32bit version. Why doesn't it take the 64bit version in system32.
Who knows. If this game is shipped with 32bit xinput in exe dir and 64 bit exe runs fine on Windows then please report a bug. If you placed this dll manually there, then we'll need some standalone test program to see how it's supposed to work on windows.
Wine-devel is not a good place to discuss that actually. You could try forums/appdb first for directions and file a bug if there isn't any.
Regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-02-06 um 12:53 schrieb Patrick Rudolph:
So system32 contains 64bit libraries and syswow64 32bit libraries... OK. then why doesn't it look into system32 for the correct dll ?
Do you have the library set to "native" or "native, builtin" maybe?
If it is set to native, is there a native xinput in system32, e.g. due to a DirectX installation?
I tried to place a 64 bit winmm in the directory of a 32 bit application (Warcraft 3). With winmm being the default "builtin, native" it loads wine's library. In case of xinput that'll give you a library that makes the game not crash but will not find a gamepad.
With the lib set to native, builtin the game crashes with a bad image error when trying to load winmm. It doesn't fall back to builtin. There is no functional winmm.dll in syswow64 except the mini-stub.
I haven't tested the case where there's a functional native library in syswow64 (or system32 for a 32 bit app)
-
Nikolay Sivov -
Patrick Rudolph -
Stefan Dösinger