-
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
d3d9-nine: introduce forwarder DLL #155
base: main
Are you sure you want to change the base?
Conversation
e2d12a9
to
c5e1063
Compare
I just tested a build from CI and it works. |
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
We embed the forwarder into ninewinecfg because: - Wine will not copy "native" DLLs from its search path to the prefix, which breaks system installs (e.g., distro packages) and WINEDLLPATH. - winetricks doesn't know about the forwarder.
In order to avoid misbehaving on existing installs, check whether the symlink points to d3d9-nine.dll{,.so}. This also fixes an oversight for the latter case in ecb3802.
Rebased and reorganized the commits a little to be more logical. |
I can confirm that this works well with Wine's DLL overrides, Please can this be merged |
@dhewg It would be really nice to have a final decision on that MR. I think this could be in the end an useful change even for the "random" end-user gaming folks. This definitely simplifies the handling when under some (special) circumstances a WineD3D component may be preferred. 🤔 |
Sorry for dropping the ball on this... We could probably use a new maintainer here? |
From a quick look at the PR, it looks clean, but the binary dll should probably not be part of the commit. @dhewg Thanks for all the work you have done so far, you helped a great deal. |
I've already explained the presence of the prebuilt DLL. Normally I wouldn't like it either, but it's the only way to make this work with the ancient toolchain Nine currently uses in CI. Unless we decide to bring in mingw as an alternative, maybe. |
Thanks, it's been a fun ride! I'm still around of course ;) Some remarks about this PR and #158: I don't know if mingw in 20.4 is sufficient for building nine, but the decision to stay on 20.04 is of course also dated by now. Maybe it's time to switch to 22.04? But note that binaries built with it will be incompatible with older distros. So users on e.g. 20.04 (which is still supported 'till Apr 2025) won't be able to use the releases nor winetricks. But then again, maybe there're none left and everybody is on 22.04 or newer already. In case you guys consider switching to 22.04: here's an older and outdated branch with it: |
Yeah, I remember this. I still don't like it, but I accounted for it while writing this PR. Hence the inclusion of the prebuilt DLLs, which are almost empty anyway (they, by design, only contain a symbol table pointing to another DLL).
You don't want to build nine itself with mingw, if you can at all1. The nine "DLLs" are linux shared objects that link against linux shared libraries, so they must be built with a linux toolchain/winegcc. But mingw would be able to build the forwarder DLL, since it's an actual PE object and doesn't contain any code. That would purely remain a workaround for building against older Wine versions.
We need at least Wine 7.3 to build this correctly (see the diff). It looks like Ubuntu 22.04 only includes Wine 6.0 still, which is what you're currently using in CI. However, the winehq repo seems to provide Wine 8.0, so that should allow the workaround to be removed. Wine 8.0 is over a year old and even debian bookworm seems to have it (https://packages.debian.org/bookworm/wine) so I'm not worried about distro compatibility too much personally. Footnotes
|
Yeah, for the sake of the argument I was simplifying the mingw thing there ;) To me such a step isn't just about this forwarder thing, it's, as you mentioned, also a requisite for the unix/pe split. That would already be a big win for nine. Split it, and use thunks like wine does, so users don't need a ton of 32bit libraries on a 64bit distro to run 32bit games on wine. Then, while wine isn't there yet, usable wayland support doesn't seem to be far off, yet everything nine is hardwired to X11 atm... Potentially ripping out old cruft like dri2 (@axeldavy should ack that though) to ease the unix/pe split would definitely help there too. So to keep nine alive it's probably time to switch to 22.04 with winehq 8.0 packages. v9.0 is already out, and wine is a faster moving target anyway (i.e. users are more likely to update wine than their distro). If the next nine release had that unix/pe split, that'd be totally awesome, but it's obvious developer time is the bottleneck here. Bottom line is: if you're up to it, go for it! I'd even merge the required CI changes |
Pending #154, this includes its commits because it depends on them.This PR introduces a new PE module, d3d9-nine-forwarder.dll, which contains no code, but exports all the d3d9.dll symbols as forwards to d3d9-nine.dll. This allows installing it as d3d9.dll while retaining the ability to customize the override settings.
ninewinecfg changes untested for now.