Skip to content
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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

d3d9-nine: introduce forwarder DLL #155

wants to merge 3 commits into from

Conversation

9ary
Copy link
Contributor

@9ary 9ary commented Mar 18, 2023

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.

@9ary 9ary force-pushed the forwarder branch 2 times, most recently from e2d12a9 to c5e1063 Compare March 19, 2023 09:37
@9ary
Copy link
Contributor Author

9ary commented Mar 19, 2023

I just tested a build from CI and it works.

@9ary 9ary marked this pull request as ready for review March 19, 2023 09:54
@9ary 9ary marked this pull request as draft March 19, 2023 10:38
@9ary 9ary marked this pull request as ready for review March 19, 2023 13:27
ninewinecfg/main.c Outdated Show resolved Hide resolved
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.
@9ary
Copy link
Contributor Author

9ary commented Apr 12, 2023

Rebased and reorganized the commits a little to be more logical.

@9ary 9ary mentioned this pull request Apr 12, 2023
@alextrical
Copy link

I can confirm that this works well with Wine's DLL overrides, Please can this be merged

@lorn10
Copy link

lorn10 commented Dec 8, 2023

@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. 🤔

@wamserma
Copy link

wamserma commented Feb 8, 2024

@dhewg Upvoting this MR. The changes by @9ary enabled me to run older DirectX9-Games on an older Laptop with Arrandale CPU (with Ironlake iGPU, no Vulkan/D3VK support) under Lutris/Wine/NixOS.

@dhewg
Copy link
Collaborator

dhewg commented Feb 12, 2024

Sorry for dropping the ball on this...
I just barely run games these days, let alone work on nine.

We could probably use a new maintainer here?

@axeldavy
Copy link
Collaborator

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 guess I'll take charge until a volunteer pops up.

@9ary
Copy link
Contributor Author

9ary commented Feb 13, 2024

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.

@dhewg
Copy link
Collaborator

dhewg commented Feb 14, 2024

@dhewg Thanks for all the work you have done so far, you helped a great deal.
I guess I'll take charge until a volunteer pops up.

Thanks, it's been a fun ride! I'm still around of course ;)

Some remarks about this PR and #158:
We use 20.04 LTS for CI with an older WINE release on purpose. It's actually a carefully balanced choice, because we're building official binary releases with this CI setup and since we're shipping binaries we need to consider binary compatibility. On top of that our releases can be installed via winetricks, where winetricks is able to fetch and install the latest (read: future) releases. Which is pretty neat and as easy as it gets, so changes to the CI setup need to consider this.

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:
https://github.com/dhewg/wine-nine-standalone/tree/22.04
We switched to winehq wine packages since then, and I'd keep that, so it needs to be rebased accordingly, but at least it should be salvageable ;)

@9ary
Copy link
Contributor Author

9ary commented Feb 14, 2024

We use 20.04 LTS for CI with an older WINE release on purpose. It's actually a carefully balanced choice, because we're building official binary releases with this CI setup and since we're shipping binaries we need to consider binary compatibility. On top of that our releases can be installed via winetricks, where winetricks is able to fetch and install the latest (read: future) releases. Which is pretty neat and as easy as it gets, so changes to the CI setup need to consider this.

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).

I don't know if mingw in 20.4 is sufficient for building nine,

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.

but the decision to stay on 20.04 is of course also dated by now. Maybe it's time to switch to 22.04?

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

  1. This would probably change if nine adopted the split unix/PE architecture of modern wine. Wine requires mingw for its own build nowadays and I suspect it's for this reason.

@dhewg
Copy link
Collaborator

dhewg commented Feb 14, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants