Missing dll version properties
What exactly do these games check for and what information would the DXVK DLLs need to provide? I'm not familiar with Windows DLL versioning.
The meta data inside the dll provided by the .rc
Here is the .rc of a d3d11 dll https://hastebin.com/vefovefowu.bash
You can have a look at the various .rc files in the wine source.
Wine's "version.rc" attached. (EDIT: For d3d11.dll)
version.rc.gz
Looking at the https://www.transmissionzero.co.uk/computing/building-dlls-with-mingw/ i guess the d3d11 version.rc file could be something like i attach here. I can use windres on it, and link it to the d3d11.dll.
Probably not a good idea to use "CompanyName: Microsoft" on it tho, cos of possibly legal issues, depending on WHAT the game actually checks this should be no problem? Ie. if its version only, i see no issues keeping a "windows dll version" as long as the other stuff is changed?
Anyway, i have been stabbing around in total darkness trying to figure out how meson can build this file with windres x86_64-w64-mingw32-windres, but i dont have a clue how to achieve this as im a total meson n00b.
Supposedly its to use some windows.compile_resources(), but "windows" is a unknown thing, and i dont know how to fiddle with that.
Attaching a suggestion to version.rc file from the info posted earlier.
version.rc.gz
In wine, there is VALUE "CompanyName", "Microsoft Corporation" /* GameGuard depends on this */. So some anti-cheat toolkit check for Microsoft as well. I don't know if it's safe for dxvk although regarding the legal issues.
What exactly do these games check for and what information would the DXVK DLLs need to provide? I'm not familiar with Windows DLL versioning.
For now. Just the usual version information present in dlls is fine. We don't have to use "Microsoft" etc. The game just need some version so it doesn't fail. We probably want to keep the version the same as Windows though.
For doing that with meson and winelib you could have a look at:
https://github.com/iXit/wine-nine-standalone/blob/master/meson.build#L51
https://github.com/iXit/wine-nine-standalone/blob/master/d3d9-nine/meson.build#L3
https://github.com/iXit/wine-nine-standalone/blob/master/d3d9-nine/version.rc
@dhewg
Quick glance on a couple of those links and i got a couple of ideas to try :)
Thx.
@dhewg Thanks for the tips! Was able to make that work, but since DXVK currently do not create the "fakedlls" when building winelib, so i disabled this "function" for the dll.so's.
@doitsujin Created a PR: https://github.com/doitsujin/dxvk/pull/993
Take a look at see if its of any use.
Example: (The "real" is to the left)
Can anyone test if #993 fixes Shattered Horizon? If so, does it still work when removing the "Copyright", "Company Name" and "Product Name" lines?
I'm concerned about the legal implications of slapping the Microsoft name onto the project, even if it is required for certain applications to work.
Can anyone test if #993 fixes Shattered Horizon? If so, does it still work when removing the "Copyright", "Company Name" and "Product Name" lines?
I'm concerned about the legal implications of slapping the Microsoft name onto the project, even if it is required for certain applications to work.
I will test it.
Copyright should possibly be: "zlib/libpng license"? (The project license)?
#993 Fixed the Shattered Horizon. Removing "Copyright", "Company Name" and "Product Name" lines also works. But I would rather keep them and use "DXVK Project" for example.
Alright, thanks. Will do something like that then.
Made a push to my fork that builds "fake_dlls" if you build --winelib with the aforementioned versioning.
If that can be of any use, although i don't really see it, you kinda need to overwrite wine dll.so's and fakedll's with these, so that you would use it without dll overrides or anything, kinda like if it was "native wine".
As i said, dunno if it is worth the trouble for dll versioning? Anyway, for lulz and gigglez i guess:
https://github.com/SveSop/dxvk/commit/7632ffb1dac52347f14c2a4d1ced4776d6e28b7d
edited: useless
Hi, is it possible as part of the build process to add the actual DXVK Version & Arch into the version properties? Knowing that you have the wrong or outdated DLL can sometimes be a bit tricky.
I understand that compatibility issues are at play, perhaps add the LegalTrademarks property, i.e. "DXVK, version: x32 v2.5.2"
Would make troubleshooting much simpler.
Thanks!
@29039 Hi there. The version is already printed in the hud and log you in case you didn't know.
Edit: bitness too in the log but that doesn't generate if the wrong one is used
Upstream links
- doitsujin/dxvk/pull/993x2 2019-04
- ValveSoftware/Proton/issues/2393x1 2019-03
DLLs
d3d11.dllx2 2019-03
Currently the generated dlls doesn't contain any version properties. You can check it on Windows via right checks and choose properties and then details. On Linux, you can also check it via exiftools and see that version properties are missing.
Some games check for the version of d3d dlls at start. Please see https://github.com/ValveSoftware/Proton/issues/2393 for details.
Related link: https://www.transmissionzero.co.uk/computing/building-dlls-with-mingw/ #Adding Version Information and Comments to your DLL shows how to add version information to dlls.