d3d9-nine: introduce forwarder DLL

[9ary]

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]

I just tested a build from CI and it works.

[9ary]

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

[alextrical]

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

[lorn10]

@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. :thinking:

[wamserma]

@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]

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]

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]

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]

@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]

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 all[^1]. 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.

[^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.

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.

[dhewg]

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