[Bug 51063] New: Version changes in Wine 6.7 break Spitfire Audio plugins
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(a)winehq.org Reporter: mail(a)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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 Sveinar Søpler <cybermax(a)dexter.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax(a)dexter.no --- Comment #1 from Sveinar Søpler <cybermax(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #2 from Robbert van der Helm <mail(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #3 from Sveinar Søpler <cybermax(a)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 :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #4 from Robbert van der Helm <mail(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #5 from Sveinar Søpler <cybermax(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 grantgj(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |grantgj(a)gmail.com --- Comment #6 from grantgj(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #7 from grantgj(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #8 from Sveinar Søpler <cybermax(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #9 from Sveinar Søpler <cybermax(a)dexter.no> --- https://github.com/wine-mirror/wine/commit/ea50d41b3f5f9b3565bfa2831f8f37aeb... Should be a fix for DCS_Updater in wine-6.8 it seems :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 Gijs Vermeulen <gijsvrm(a)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(a)gmail.com> --- Robbert, is this still an issue with wine-7.0rc1? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #11 from Robbert van der Helm <mail(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #12 from Hans Leidekker <hans(a)meelstraat.net> --- Can we close this bug? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #13 from Robbert van der Helm <mail(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #14 from Hans Leidekker <hans(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #15 from Robbert van der Helm <mail(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #16 from Hans Leidekker <hans(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #17 from Gijs Vermeulen <gijsvrm(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 --- Comment #18 from Robbert van der Helm <mail(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 Gijs Vermeulen <gijsvrm(a)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(a)gmail.com> --- In that case, marking FIXED. Robbert, please open a new bug for the remaining (non-regression) issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51063 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #20 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 7.0-rc4. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla