https://bugs.winehq.org/show_bug.cgi?id=51063
Bug ID: 51063 Summary: Version changes in Wine 6.7 break Spitfire Audio plugins Product: Wine Version: 6.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: mail@robbertvanderhelm.nl Regression SHA1: 04a8213ba9e3b8aa1f980d19b240929948da5abe Distribution: ---
The LABS and BBC Symphony Orchestra Discover plugins can no longer find their sample libraries as of Wine 6.7, and they'll show a generic 'Error #1: Something went wrong' error message instead. After bisecting, it seems like commit 04a8213 caused this regression. That commit changes WINE_FILEVERSION and WINE_PRODUCTVERSION to match Windows 10 instead of Windows 7. There aren't any new or different warnings or fixmes printed between Wine 6.6 (where those plugins did work correctly) and Wine 6.7 (where they don't), but I've only tested that with WINEDEBUG's defaults. Reverting the commit on the master branch makes the plugins work again as expected. I tested this with the 64-bit VST3 versions of BBCSOD 1.1.9 and LABS 1.3.7 under yabridge 3.1.1 (or, well, the version that's to become 3.1.1).
https://source.winehq.org/git/wine.git/commit/04a8213ba9e3b8aa1f980d19b24092...
https://bugs.winehq.org/show_bug.cgi?id=51063
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #1 from Sveinar Søpler cybermax@dexter.no --- Probably a stupid question, but have you tried to set your wineprefix to Win10? Logic being that if the program assumes the OS is win 7, it expects the dll version to be that of win 7...
The default prefix os-version is Windows7.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #2 from Robbert van der Helm mail@robbertvanderhelm.nl --- @Sveinar Søpler
Check the commit I linked for the version changes I'm talking about. These two version strings are independent of the Windows version you select in winecfg. While I was bisecting this, the Windows version option in winecfg was kept at Windows 7 the entire time.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #3 from Sveinar Søpler cybermax@dexter.no --- (In reply to Robbert van der Helm from comment #2)
@Sveinar Søpler
Check the commit I linked for the version changes I'm talking about. These two version strings are independent of the Windows version you select in winecfg. While I was bisecting this, the Windows version option in winecfg was kept at Windows 7 the entire time.
That is why i used the phrase:
Logic being that if the program assumes the OS is win 7, it expects the dll version to be that of win 7...
And updating the .dll version to that of Win10 without actually setting the prefix to win10 COULD cause issues if a program checks for both. I have no idea what checks is done by this particular program, but i know of a few instances where checks is being done for OS, and if OS = win10, it checks the .dll version to determine what build you are using, so spesific settings can be used.
If you have tried, and it makes no difference, i am sorry for the suggestion :)
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #4 from Robbert van der Helm mail@robbertvanderhelm.nl --- Ah yes, I get you, sorry. Changing the reported Windows version in winecfg doesn't have any noticeable effect here. The plugin will keep throwing this generic 'Error #1: Something went wrong' regardless of which OS version you select in winecfg.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #5 from Sveinar Søpler cybermax@dexter.no --- (In reply to Robbert van der Helm from comment #4)
Ah yes, I get you, sorry. Changing the reported Windows version in winecfg doesn't have any noticeable effect here. The plugin will keep throwing this generic 'Error #1: Something went wrong' regardless of which OS version you select in winecfg.
Right. Atleast an easy check to do, just in case it was that simple :)
Then i guess i am at a loss for now. Could be some functions the program expect to be there if you have that particular .dll version, which wine does not support maybe.
I'll tinker a bit with a game i know checks kernel32.dll version to determine what buildnumber is in use, and see if i can come up with a WINEDEBUG line you could check with.
https://bugs.winehq.org/show_bug.cgi?id=51063
grantgj@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grantgj@gmail.com
--- Comment #6 from grantgj@gmail.com --- Hi i suspect this also affects dcs worlds updater DCS_update.exe no matter the version selected in winecfg it throws an error about windows version needs to be 8.1 or 10 to update now.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #7 from grantgj@gmail.com --- sorry please ignore my comment, dcs issue was not caused by changes to version.rc after learing to do bisect it looks to be this commit instead.
[2d519f5aa451513a6e12dec7855c08cd1b8d12fb] ntdll: Support MaxVersionTested in the manifest compatibility element.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #8 from Sveinar Søpler cybermax@dexter.no --- I did not have any issues running DCS_updater.exe with wine-staging-6.8.
I did not download the whole 47GB game, but running DCS_updater.exe stopping it and re-run it seemed to work without any complaints about os. Is it something that happens only once the full game is installed?
Could you test with wine-staging-6.8 and if it still fails, maybe just recreate your prefix with wine-staging-6.8 and just copy the Program Files/Eagle Dynamics folder over to the new prefix and run the DCS_updater.exe then? Cannot guarantee how it works, but hopefully it would be "smart" enough to do a repair or something without the need to download the full game again?
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #9 from Sveinar Søpler cybermax@dexter.no --- https://github.com/wine-mirror/wine/commit/ea50d41b3f5f9b3565bfa2831f8f37aeb...
Should be a fix for DCS_Updater in wine-6.8 it seems :)
https://bugs.winehq.org/show_bug.cgi?id=51063
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Version changes in Wine 6.7 |Spitfire Audio plugins can |break Spitfire Audio |find their sample libraries |plugins | Keywords| |regression
--- Comment #10 from Gijs Vermeulen gijsvrm@gmail.com --- Robbert, is this still an issue with wine-7.0rc1?
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #11 from Robbert van der Helm mail@robbertvanderhelm.nl --- This particular issue (related to commit 04a8213) where the plugins just wouldn't be able to find their sample libraries at all has been resolved. At least a couple releases back these plugins still seem to spuriously report that they can't find their sample libraries for some people with reinstalling everything to a clean Wine prefix being the only solution I've found, but I've never tried figuring out what exactly is causing that.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #12 from Hans Leidekker hans@meelstraat.net --- Can we close this bug?
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #13 from Robbert van der Helm mail@robbertvanderhelm.nl --- I guess so (I also just noticed that there's a typo in the title).
If I or someone else ever figures out what's causing the more general issue of this software randomly not being able to find the sample library directories then I'll create another ticket.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #14 from Hans Leidekker hans@meelstraat.net --- (In reply to Robbert van der Helm from comment #13)
I guess so (I also just noticed that there's a typo in the title).
If I or someone else ever figures out what's causing the more general issue of this software randomly not being able to find the sample library directories then I'll create another ticket.
If it's consistently fixed by recreating the prefix that suggests the application has an install time dependency on the reported kernel32 version.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #15 from Robbert van der Helm mail@robbertvanderhelm.nl --- This issue has existed for as long as I remember (since at least Wine 5.0), so I'm not sure if that's the case. My guess would be that some native library override is interfering, but this software is doing more strange things so the actual cause behind all of this will probably pop up eventually. They also seem to remember the installation directory from the previous prefix even after disabling the desktop integration for the documents directories and such.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #16 from Hans Leidekker hans@meelstraat.net --- (In reply to Robbert van der Helm from comment #15)
This issue has existed for as long as I remember (since at least Wine 5.0),
In that case I don't understand why this is reported as a regression against Wine 6.7.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #17 from Gijs Vermeulen gijsvrm@gmail.com --- (In reply to Hans Leidekker from comment #16)
(In reply to Robbert van der Helm from comment #15)
This issue has existed for as long as I remember (since at least Wine 5.0),
In that case I don't understand why this is reported as a regression against Wine 6.7.
As far as I understood, this regression prevented the plugins from finding their sample libraries _at all_, while the general, earlier issue is that it spuriously can't find them.
https://bugs.winehq.org/show_bug.cgi?id=51063
--- Comment #18 from Robbert van der Helm mail@robbertvanderhelm.nl --- (In reply to Gijs Vermeulen from comment #17)
As far as I understood, this regression prevented the plugins from finding their sample libraries _at all_, while the general, earlier issue is that it spuriously can't find them.
That is correct.
https://bugs.winehq.org/show_bug.cgi?id=51063
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Summary|Spitfire Audio plugins can |Spitfire Audio plugins |find their sample libraries |can't find their sample | |libraries Status|UNCONFIRMED |RESOLVED
--- Comment #19 from Gijs Vermeulen gijsvrm@gmail.com --- In that case, marking FIXED. Robbert, please open a new bug for the remaining (non-regression) issue.
https://bugs.winehq.org/show_bug.cgi?id=51063
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.0-rc4.
-
WineHQ Bugzilla