-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting a native DLL override for d3d9 is incorrect #150
Comments
It's only a fake DLL if installed in a certain way. Usually it is a unix library without the corresponding fake DLL. The override is required on some WINE versions at least. When did that change? |
I doubt Wine has ever considered the .dll.so to be a native DLL, and it definitely doesn't think the fake DLL is one. Since 5.7 is apparently the oldest supported version, it'd be good to check what happens there. |
"native override" doesn't necessarily mean there's a win32 native DLL. The override is required so WINE picks up a d3d9.dll copy from a prefix at all. Without it it would always use the wined3d copy from the WINE installation. But since your arch package does the nine<->wine integration that picture changes and the override apparently gets useless and redundant. |
I've packaged this project for NixOS as well (see #153), and I do not use the fake DLLs at all there. Nothing is installed to Wine's system path. Wine picks up d3d9.dll just fine with no override set at all. I just did an experiment and the results are interesting. This is on Arch, Wine 8.3, nine 0.8. I've installed the (proper) d3d9.dll from nine into the Fusion 360 directory. AdCefWebBrowser.exe is in a subdirectory, so it never sees this DLL (I want it to use wined3d, due to rendering issues with nine).
So it seems that Wine will load nine regardless of the override setting unless it's disabled. This sounds like a wine bug, unix libraries should be treated as builtin DLLs. Messing with overrides for d3d9-nine.dll (with the fake dll installed to the prefix's system32):
This is the correct behavior. |
I'd have to test it again to make sure, but that sounds like a change in WINE behaviour to me. |
I've managed to work around this by creating a DLL with no code, but all symbols forwarded to d3d9-nine. This DLL is recognized by wine as a native DLL, so I can drop it in system32, set a global override to builtin, and then an application-specific override for Fusion360.exe to native. The result is as expected: Fusion uses nine, and nothing else. The downside is that I had to use mingw for this, it would be nice to figure out how to do this using winegcc instead, to avoid adding an extra build dependency. d3d9.def (can be generated from the .spec with winebuild and then running a simple sed on the output):
Compile with Here's what happens if I try to use winegcc:
Edit: I managed to make a DLL using winebuild, but for some reason it causes Fusion to be unresponsive for a while at startup before it becomes usable. This isn't a problem with the mingw DLL... |
Because Wine appears to ignore override settings for .dll.so libraries, introduce a forwarding DLL that will always be identified as native. Fixes iXit#150
Because Wine appears to ignore override settings for .dll.so libraries, introduce a forwarding DLL that will always be identified as native. Fixes iXit#150
Because Wine appears to ignore override settings for .dll.so libraries, introduce a forwarding DLL that will always be identified as native. Fixes iXit#150
Because Wine appears to ignore override settings for .dll.so libraries, introduce a forwarding DLL that will always be identified as native. Fixes iXit#150
Because Wine appears to ignore override settings for .dll.so libraries, introduce a forwarding DLL that will always be identified as native. Fixes iXit#150
d3d9-nine.dll is a fake DLL, so setting a DLL override to native is incorrect. Installing it as d3d9.dll is sufficient, nine still works with the override removed.
To clarify: setting a DLL override to native means that wine should only load real DLLs, setting it to builtin means it should only load fake DLLs.
The text was updated successfully, but these errors were encountered: