June 2021 - Wine-Bugs - list.winehq.org

[Bug 51324] Imperium Great Battles of Rome can't play videos

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51324 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs(a)winehq.org |gijsvrm(a)gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Created attachment 70219 --> https://bugs.winehq.org/attachment.cgi?id=70219 patch Hi Lorenzo, Thanks for the detailed explanation, it seems the main problem is that we weren't handling AMMSF_RENDERALLSTREAMS in OpenFile() at all. Does the attached patch work for you as well? If so, I'll send it upstream. -- 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.

June 30, 2021

[Bug 51364] Battle.net doesn't start on wine staging, built from git

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51364 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winsock Regression SHA1| |414b31bc0bbbfe005e90a1946a6 | |49082dc303c55 Product|Wine-staging |Wine -- 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.

June 30, 2021

[Bug 51364] New: Battle.net doesn't start on wine staging, built from git

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51364 Bug ID: 51364 Summary: Battle.net doesn't start on wine staging, built from git Product: Wine-staging Version: 6.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cysp74(a)posteo.net CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 70218 --> https://bugs.winehq.org/attachment.cgi?id=70218 logentries Battle.net doesn't start wine staging, built from git. Last working commit is: https://github.com/wine-staging/wine-staging/commit/fd5866f6f12e82afc74a21e… Attaching some log entries. Related env variables: export __GL_THREADED_OPTIMIZATIONS=0 export __GL_SHADER_CACHE="${SCRIPTHOME}/shadercache" export __GL_SHADER_DISK_CACHE_PATH="${SCRIPTHOME}/shadercache" export DXVK_STATE_CACHE_PATH="${SCRIPTHOME}/dxvkcache" export MESA_GLTHREAD=FALSE export STAGING_SHARED_MEMORY=1 export STAGING_WRITECOPY=1 export GPU_MAX_HEAP_SIZE=100 export GPU_MAX_ALLOC_PERCENT=100 Played with __GL_THREADED_OPTIMIZATIONS, STAGING_SHARED_MEMORY, STAGING_WRITECOPY. No effect settings these true/false/on/off. DXVK 1.9 installed. Ty -- 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.

June 30, 2021

[Bug 51363] user32:dde times out on cw-*-1507 machines, pollutes other tests

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51363 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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.

June 30, 2021

[Bug 51363] New: user32:dde times out on cw-*-1507 machines, pollutes other tests

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51363 Bug ID: 51363 Summary: user32:dde times out on cw-*-1507 machines, pollutes other tests Product: Wine Version: 6.10 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The timeouts are not systematic but still pretty frequent: https://test.winehq.org/data/patterns.html#user32:dde 0a24:dde: 82 tests executed (0 marked as todo, 0 failures), 0 skipped. user32:dde:0220 done (258) in 120s They happen on the same set of machines as the user32:sysparams timeouts (bug 51362) so they are likely to share a common cause: a rogue window that does not process some broadcast message. A side effect of the timeout is that subprocesses started by user32:dde terminate late and issue a test failure while other tests are running. For instance: wave.c:1223: waveOutOpen(WAVE_MAPPER): WAVE_FORMAT_IMA_ADPCM not supported dde.c:1015: Test failed: Unhandled msg: 000003e1 Misplaced failure line 03bc:dde: 28 tests executed (0 marked as todo, 1 failure), 0 skipped. wave.c:1599: writing 44101 bytes then 44099 bytes -- 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.

June 30, 2021

[Bug 51362] user32:sysparams times out on the cw-* Windows 10 1507 machines

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51362 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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.

June 30, 2021

[Bug 51362] New: user32:sysparams times out on the cw-* Windows 10 1507 machines

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51362 Bug ID: 51362 Summary: user32:sysparams times out on the cw-* Windows 10 1507 machines Product: Wine Version: 6.10 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com user32:sysparams times out on the cw-* Windows 10 1507 machines: https://test.winehq.org/data/patterns.html#user32:sysparams sysparams.c:1123: testing SPI_{GET,SET}ICONTITLEWRAP user32:sysparams:04d8 done (258) in 120s It used to time out on most cw-rx460 configurations because the 19.* Radeon driver created a window that did not process the messages broadcasted by the first SystemParametersInfo(... SPIF_SENDCHANGE) call. However this was resolved by: * Upgrading to the 21.* Radeon driver which does not have this issue. * Reinstalling the 19.11.3 driver without its configuration GUI. Despite that it still systematically times out on cw-rx460-1507 so there must be some other window causing trouble. user32:sysparams also times out on cw-gtx560-1507 but not systematically. The reason for this timeout is unknown but it is likely caused by some rogue window too. user32:sysparams never times out on the QEmu VMs, including w1064v1507 so it seems likely that the issue is related to some aspect specific to the cw-* machines. -- 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.

June 30, 2021

[Bug 51361] New: SimSig with Wine 6.11 breaks after upgrading from libxml2 2.9.10 to 2.9.12

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51361 Bug ID: 51361 Summary: SimSig with Wine 6.11 breaks after upgrading from libxml2 2.9.10 to 2.9.12 Product: Wine Version: 6.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msxml3 Assignee: wine-bugs(a)winehq.org Reporter: bugs(a)chead.ca Distribution: --- Launching the SimSig launcher with Wine 6.11 and libxml2 2.9.10 works fine. After upgrading to libxml2 2.9.12, the software no longer works properly, and the following shows up in the console output: 0104:fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT/DATA_SEND_TIMEOUT 5000 0024:fixme:ieframe:PersistStreamInit_Load (002B8CD8)->(002B2130) 0024:fixme:ieframe:PersistStreamInit_InitNew (0028C590) 0024:err:ole:apartment_add_dll couldn't load in-process dll L"C:\\windows\\system32\\msxml3.dll" 0024:err:ole:create_server class {f5078f32-c551-11d3-89b9-0000f81fe221} not registered 0024:err:ole:com_get_class_object no class object {f5078f32-c551-11d3-89b9-0000f81fe221} could be created for context 0x5 0024:err:module:find_forwarded_export module not found for forward 'msxml3.DllGetClassObject' used by L"C:\\windows\\system32\\msxml2.dll" 0024:err:ole:apartment_add_dll couldn't find function DllGetClassObject in L"C:\\windows\\system32\\msxml2.dll" 0024:err:ole:create_server class {f5078f1b-c551-11d3-89b9-0000f81fe221} not registered 0024:err:ole:com_get_class_object no class object {f5078f1b-c551-11d3-89b9-0000f81fe221} could be created for context 0x5 0024:err:module:find_forwarded_export module not found for forward 'msxml3.DllGetClassObject' used by L"C:\\windows\\system32\\msxml.dll" 0024:err:ole:apartment_add_dll couldn't find function DllGetClassObject in L"C:\\windows\\system32\\msxml.dll" 0024:err:ole:create_server class {2933bf90-7b36-11d2-b20e-00c04f983e60} not registered 0024:err:ole:com_get_class_object no class object {2933bf90-7b36-11d2-b20e-00c04f983e60} could be created for context 0x5 There is a lot more output, but it is either benign messages that also appear with 2.9.10, or else repeats of the same messages. I have recompiled Wine after installing the new libxml2, but that did not make any difference; the problem still occurs. -- 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.

June 30, 2021

[Bug 51360] New: vkGetDeviceProcAddr invalid behavior for functions from extensions unsupported by host Vulkan instance

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51360 Bug ID: 51360 Summary: vkGetDeviceProcAddr invalid behavior for functions from extensions unsupported by host Vulkan instance Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winevulkan Assignee: wine-bugs(a)winehq.org Reporter: loothelion(a)nvidia.com Distribution: --- I believe the below may also be true for vkGetInstanceProcAddr, but I haven't confirmed this locally. The Vulkan 1.2.182 specification states the following about the behavior of vkGetDeviceProcAddr: > The table below defines the various use cases for vkGetDeviceProcAddr and > expected return value for each case. > > The returned function pointer is of type PFN_vkVoidFunction, and must be cast to > the type of the command being queried before use. The function pointer must only > be called with a dispatchable object (the first parameter) that is device or a > child of device. > > Table 2. vkGetDeviceProcAddr behavior > > device | pName | return value > --------------------------------------------------------------------------------------- > NULL | *[1] | undefined > --------------------------------------------------------------------------------------- > invalid device | *[1] | undefined > --------------------------------------------------------------------------------------- > device | NULL | undefined > --------------------------------------------------------------------------------------- > device | core device-level Vulkan command [2] | fp[3] > --------------------------------------------------------------------------------------- > device | enabled extension device-level commands [2] | fp[3] > --------------------------------------------------------------------------------------- > any other case, not covered above | NULL > > [1] - "*" means any representable value for the parameter (including valid > values, invalid values, and NULL). > > [2] - In this function, device-level excludes all physical-device-level > commands. > > [3] - The returned function pointer must only be called with a dispatchable > object (the first parameter) that is device or a child of device e.g. > VkDevice, VkQueue, or VkCommandBuffer. Winevulkan's behavior differs from this slightly. Note the fifth row of the table uses the language "enabled extension device-level commands", this means that if a command is queried via vkGetDeviceProcAddr and isn't part of core, the extension which introduces it must be enabled for the given VkDevice object in order for vkGetDeviceProcAddr to return a valid function pointer, and otherwise it should return NULL. In order to properly conform to the Vulkan specification Winevulkan should only expose device-level commands whose extensions have been enabled. Note that applications should not be querying for Vulkan commands via vkGetDeviceProcAddr if they know the extension is not supported by the underlying implementation. However in the case of an application which does rely on this bad behavior, Winevulkan will return a function pointer to one of its thunks and then proceed to deference a null function pointer when it tries to call into the underlying host Vulkan implementation. -- 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.

June 30, 2021

[Bug 51214] rundll.exe and winoldap.mod crash

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=51214 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Component|-unknown |ntdll Status|NEW |RESOLVED Fixed by SHA1| |cbf7a101763790ca03307c72d32 | |dd8969a381be6 --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- Fixed by <https://source.winehq.org/git/wine.git/commitdiff/cbf7a101763790ca03307c72d…>; thanks Bernhard. -- 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.

June 30, 2021