March 2023 - Wine-Bugs - list.winehq.org

[Bug 54661] winscard:winscard - The 32-bit test crashes in Wine due to incorrect libpcsclite function signatures

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54661 --- Comment #8 from François Gouget <fgouget(a)codeweavers.com> --- Created attachment 74177 --> https://bugs.winehq.org/attachment.cgi?id=74177 WIP winscard: Fix 32-bit support. This is enough to fix the 32-bit winscard tests (both pure 32-bit and '32-bit in a 64-bit wineprefix' as of today). However this is more involved than I initially thought and it appears this is not the right direction anyway. So I'll stop there. -- 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.

March 10, 2023

[Bug 54661] winscard:winscard - The 32-bit test crashes in Wine due to incorrect libpcsclite function signatures

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54661 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to François Gouget from comment #6) > > The plan is to support 32-bit code through Wow64 thunks. > > Okay. What I meant is that then a pure 32-bit Wine build should not provide > a 32-bit winscard dll. Currently this very basic command produces a crash in > the tests: > > ./configure && make && ./wine > dlls/winscard/tests/i386-windows/winscard_test.exe winscard Right, I don't think we should install 32-bit development libraries on gitlab, just the 64-bit one. -- 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.

March 10, 2023

[Bug 54635] libwine backward compatibility

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54635 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #4 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Alexandre Julliard from comment #2) > The change was necessary because of the new PE/Unix architecture. The > planned incompatibility was explained in the stable release notes, in > particular the ones for 6.0. The 6.0 release notes mention that libwine was being deprecated and removed, but it doesn't mention why, and I've been increasingly wondering that. Why couldn't libwine have stayed as a unix-side library? -- 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.

March 10, 2023

[Bug 54646] Entering the minus symbol displays parentheses

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54646 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #5 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, (In reply to Pascal from comment #4) > This software is not publicly available somewhere, but i can give you the > executable file to let you see what is the problem. Please, don't share proprietary software publicly. To avoid any legal issues, use private means to share it with a developer for individual technical support, or just don't share it and just follow advice/instructions given here. (In reply to Zeb Figura from comment #1) > Are you sure this is a bug? Parentheses are a common notation for debit in > accounting. This is indeed a valid remark. Both notations are valid negative numbers representation. It looks like it depends on locale, though. @OP, Make sure that the application has no negative number notation setting that may have changed for unknown reasons. How is your locale (environment variables LANG, LC_MONETARY, LC_NUMERIC) configured? Regards. -- 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.

March 10, 2023

[Bug 52844] Call of Duty: Black Ops II stucks with a black screen after intro

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52844 --- Comment #3 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Also these 01b0:warn:d3d11:d3d11_device_context_QueryInterface {b4e3c01d-e79e-4637-91b2-510e9f4c9b8f} not implemented, returning E_NOINTERFACE. 01b0:warn:d3d11:d3d_device_inner_QueryInterface {10ec4d5b-975a-4689-b9e4-d0aac30fe333} not implemented, returning E_NOINTERFACE. 0544:warn:dxgi:d3d11_swapchain_QueryInterface {a8be2ac4-199f-4946-b331-79599fb98de7} not implemented, returning E_NOINTERFACE 0544:warn:dxgi:d3d11_swapchain_QueryInterface {94d99bdb-f1f8-4ab0-b236-7da0170edab1} not implemented, returning E_NOINTERFACE -- 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.

March 10, 2023

[Bug 54661] winscard:winscard - The 32-bit test crashes in Wine due to incorrect libpcsclite function signatures

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54661 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|8490c43f38e306fef7b5fed3ffc |77fdfdb8ef09153bf0adbfa6226 |b256efd73af58 |b6477b4dd0702 --- Comment #6 from François Gouget <fgouget(a)codeweavers.com> --- (In reply to Hans Leidekker from comment #4) > (In reply to François Gouget from comment #3) > > So I could point at the commit that introduced the tests but the one I > > pointed to is the one that will cause 32-bit Windows applications to fail. > > Most likely they would already fail since the dll was a stub. I guess that's a fair point. Unlike our tests they probably stop on all SCardAccessStartedEvent() errors, not just on SCARD_E_NO_SERVICE. So getting that, SCARD_F_INTERNAL_ERROR (stub), or SCARD_E_INVALID_PARAMETER (current code) probably makes no difference to them. I'm updating the regression SHA1 then. [...] > > Now if the plan is to not support 32-bit code, then Wine should not provide > > a 32-bit winscard dll. > > The plan is to support 32-bit code through Wow64 thunks. Okay. What I meant is that then a pure 32-bit Wine build should not provide a 32-bit winscard dll. Currently this very basic command produces a crash in the tests: ./configure && make && ./wine dlls/winscard/tests/i386-windows/winscard_test.exe winscard And running the 32-bit test in a 64-bit wineprefix crashes too: https://test.winehq.org/data/patterns.html#winscard:winscard -- 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.

March 10, 2023

[Bug 54661] winscard:winscard - The 32-bit test crashes in Wine due to incorrect libpcsclite function signatures

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54661 --- Comment #5 from Hans Leidekker <hans(a)meelstraat.net> --- A related issue that the 32-bit development package has dependency problems, on 64-bit Debian at least. -- 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.

March 10, 2023

[Bug 54661] winscard:winscard - The 32-bit test crashes in Wine due to incorrect libpcsclite function signatures

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54661 --- Comment #4 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to François Gouget from comment #3) > Why this is a regression: there was no test and thus no test failures. Now > the 32-bit tests crash which is a failure. So the Wine tests regressed. > > So I could point at the commit that introduced the tests but the one I > pointed to is the one that will cause 32-bit Windows applications to fail. Most likely they would already fail since the dll was a stub. > Dealing with the DWORD parameters that are passed directly to libpcsclite is > easy enough. The hard part is dealing with the structures: reader_state, > io_request, and the void* parameters of SCardGetAttrib() and > SCardSetAttrib(). Exactly. > Now if the plan is to not support 32-bit code, then Wine should not provide > a 32-bit winscard dll. The plan is to support 32-bit code through Wow64 thunks. -- 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.

March 10, 2023

[Bug 54661] winscard:winscard - The 32-bit test crashes in Wine due to incorrect libpcsclite function signatures

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54661 --- Comment #3 from François Gouget <fgouget(a)codeweavers.com> --- Why this is a regression: there was no test and thus no test failures. Now the 32-bit tests crash which is a failure. So the Wine tests regressed. So I could point at the commit that introduced the tests but the one I pointed to is the one that will cause 32-bit Windows applications to fail. Dealing with the DWORD parameters that are passed directly to libpcsclite is easy enough. The hard part is dealing with the structures: reader_state, io_request, and the void* parameters of SCardGetAttrib() and SCardSetAttrib(). Now if the plan is to not support 32-bit code, then Wine should not provide a 32-bit winscard dll. -- 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.

March 10, 2023

[Bug 54661] winscard:winscard - The 32-bit test crashes in Wine due to incorrect libpcsclite function signatures

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=54661 --- Comment #2 from Hans Leidekker <hans(a)meelstraat.net> --- Again, I don't see how this is a regression because there were no tests before this commit. My plan was to skip old-style 32-bit support because it gets very messy with the different DWORD sizes. -- 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.

March 10, 2023