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

[Bug 53905] New: widl: support MIDL 3.0 and WinMD output
by WineHQ Bugzilla Dec. 6, 2023

Dec. 6, 2023

https://bugs.winehq.org/show_bug.cgi?id=53905 Bug ID: 53905 Summary: widl: support MIDL 3.0 and WinMD output Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)winehq.org Reporter: alvin(a)alvinhc.com C++/WinRT (cppwinrt): https://github.com/microsoft/cppwinrt It is currently impossible to build the custom components in the cppwinrt test suite with mingw-w64. For this to work, widl needs to: - understand MIDL 3.0 syntax, - generate the ABI header (not required if only using C++/WinRT projection), - produce .winmd metadata of the component, - read existing system .winmd metadata (not sure if actually needed). The MIDL command line for this: midl.exe /metadata_dir C:\Windows\System32\WinMetadata /winrt /winmd "D:\a\cppwinrt\cppwinrt\_build\x64\Debug\test_component.winmd" /h "D:\a\cppwinrt\cppwinrt\_build\x64\Debug\test_component.h" /ns_prefix /nomidl test_component.idl ## MIDL 3.0 https://learn.microsoft.com/en-us/uwp/midl-3/intro What I can tell is missing widl so far: - MIDL 3.0 uses different basic type names (e.g. Int32, String) - Attribute types, and using custom attributes Example file: https://github.com/microsoft/cppwinrt/blob/5ca626adae21be363399b44d2b6a9ab3… > widl --winrt -h -H out/test_component.h --ns_prefix test_component.idl test_component.idl:5: error: syntax error, unexpected aIDENTIFIER, expecting ',' or ']' (widl version 7.7 from mingw-w64) ## WinMD metadata https://learn.microsoft.com/en-us/uwp/winrt-cref/winmd-files These are CLR (think .NET and ECMA 335) assemblies used as a replacement for the old typelib files. -- 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.

1 1

[Bug 41977] New: Gunner3 always crashes due to wine having a different allocation scheme than windows
by wine-bugs＠winehq.org Dec. 4, 2023

Dec. 4, 2023

https://bugs.winehq.org/show_bug.cgi?id=41977 Bug ID: 41977 Summary: Gunner3 always crashes due to wine having a different allocation scheme than windows Product: Wine Version: 1.9.24 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: ArchLinux Created attachment 56382 --> https://bugs.winehq.org/attachment.cgi?id=56382 Hack to get the game working, patch for the exe Gunner 3 always crashes when selecting a level. According to my debugging, it's because the game allocates memory with RtlAllocateHeap and then accesses the area before that, aka undefined behavior. But note that it works just fine on all windows versions and ReactOS. It's probably WONTFIX, but since it works on windows I'll provide a hack (and maybe a patch) for usage on linux. Attached an patch for the gunner3.exe, make sure it has the MD5 4481bc4382bb00353edf0635516d904d. -- 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.

2 6

[Bug 43418] New: gOddysey Pacemaker crashes with "User lib not found"
by wine-bugs＠winehq.org Dec. 3, 2023

Dec. 3, 2023

https://bugs.winehq.org/show_bug.cgi?id=43418 Bug ID: 43418 Summary: gOddysey Pacemaker crashes with "User lib not found" Product: Wine Version: 2.12 Hardware: x86 URL: http://web.archive.org/web/20110624013029if_/http://we bzoom.webs.com/smiff/PaceMakerR.zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Split of from Bug 43414. For me the program doesn't work at all, while the OP from Bug 43414 reported it working. Snipped from the log that looks suspicous to me: ------ 009:Ret PE DLL (proc=0x63cc6560,module=0x63c60000 L"msvcrt.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0009:Call PE DLL (proc=0x2251000,module=0x2250000 L"JV-ODE.dll",reason=PROCESS_ATTACH,res=(nil)) trace:seh:raise_exception code=c0000005 flags=0 addr=0x22c6010 ip=022c6010 tid=0009 trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=9eeef1ec trace:seh:raise_exception eax=02251000 ebx=7bd06000 ecx=b68a9cb0 edx=0033f95c esi=0033f5d8 edi=00000001 trace:seh:raise_exception ebp=0033f5b8 esp=0033f59c cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7bcc7010 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x7bca52f0 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x7bca52f0 returned 1 0009:exception in PE entry point (proc=0x2251000,module=0x2250000,reason=PROCESS_ATTACH,res=(nil)) 0009:Ret PE DLL (proc=0x2251000,module=0x2250000 L"JV-ODE.dll",reason=PROCESS_ATTACH,res=(nil)) retval=0 0009:Call PE DLL (proc=0x2251000,module=0x2250000 L"JV-ODE.dll",reason=PROCESS_DETACH,res=(nil)) trace:seh:raise_exception code=c0000005 flags=0 addr=0x22510a0 ip=022510a0 tid=0009 trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=9eedf000 trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=02250000 edx=0033f900 esi=00000001 edi=00000000 trace:seh:raise_exception ebp=0033f5b8 esp=0033f5a0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7bcc7010 code=c0000005 flags=0 trace:seh:__regs_RtlUnwind code=c0000005 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x7bca52f0 code=c0000005 flags=2 trace:seh:__regs_RtlUnwind handler at 0x7bca52f0 returned 1 0009:exception in PE entry point (proc=0x2251000,module=0x2250000,reason=PROCESS_DETACH,res=(nil)) 0009:Ret PE DLL (proc=0x2251000,module=0x2250000 L"JV-ODE.dll",reason=PROCESS_DETACH,res=(nil)) retval=0 0009:Ret KERNEL32.LoadLibraryA() retval=00000000 ret=100092fe 0009:Call KERNEL32.LoadLibraryA(0067fb94 "blitzclose.dll") ret=100092fe 0009:Call PE DLL (proc=0x2251199,module=0x2250000 L"blitzclose.dll",reason=PROCESS_ATTACH,res=(nil)) ------ It seems like it can't load the DLLs, and thus crashes. But I might be wrong. -- 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.

2 10

[Bug 48220] New: dxruby needs WAVE form loading implemented
by WineHQ Bugzilla Dec. 3, 2023

Dec. 3, 2023

https://bugs.winehq.org/show_bug.cgi?id=48220 Bug ID: 48220 Summary: dxruby needs WAVE form loading implemented Product: Wine Version: 4.20 Hardware: x86-64 URL: https://github.com/mirichi/dxruby/ OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dmusic Assignee: wine-bugs(a)winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- This refers to 'fixme:dmime:seg_IPersistStream_Load WAVE form loading not implemented'. As you can see, DirectMusicPerformance8 is being used here. ...yeah, really...even though it's been updated less than a year ago, simply because of the design goals Anyway, it doesn't crash but obviously no music is being played. -- 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.

1 6

[Bug 52673] New: Missing IShellItemImageFactory implementation for ShellItem.
by WineHQ Bugzilla Dec. 2, 2023

Dec. 2, 2023

https://bugs.winehq.org/show_bug.cgi?id=52673 Bug ID: 52673 Summary: Missing IShellItemImageFactory implementation for ShellItem. Product: Wine Version: 7.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs(a)winehq.org Reporter: jinoh.kang.kr(a)gmail.com Distribution: --- This leads to KakaoTalk crashing when displaying the thumbnail of video being uploaded. -- 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.

1 9

[Bug 53548] New: Msys2 installer UI has black background and incorrect font spacing
by WineHQ Bugzilla Dec. 1, 2023

Dec. 1, 2023

https://bugs.winehq.org/show_bug.cgi?id=53548 Bug ID: 53548 Summary: Msys2 installer UI has black background and incorrect font spacing Product: Wine Version: 7.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: joel(a)airwebreathe.org.uk Distribution: --- Created attachment 72911 --> https://bugs.winehq.org/attachment.cgi?id=72911 Msys2 installer on Wine The Msys2 installer is powered by Qt IFW (Installer Framework). When we load up the installer window, the UI looks somewhat broken. Specifically there is black rectangle along the top of the window, and the lettering is spaced out. -- 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.

1 2

[Bug 48669] New: iphlpapi.NotifyUnicastIpAddressChange() should call the callback initially if requested (required for Far Cry 5 online mode)
by WineHQ Bugzilla Dec. 1, 2023

Dec. 1, 2023

https://bugs.winehq.org/show_bug.cgi?id=48669 Bug ID: 48669 Summary: iphlpapi.NotifyUnicastIpAddressChange() should call the callback initially if requested (required for Far Cry 5 online mode) Product: Wine Version: 5.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: iphlpapi Assignee: wine-bugs(a)winehq.org Reporter: gofmanp(a)gmail.com Distribution: --- Created attachment 66526 --> https://bugs.winehq.org/attachment.cgi?id=66526 Patch Far Cry 5 fails to connect to online mode due to the missing part of initialization which is done from NotifyUnicastIpAddressChange() callback. The callback is supposed to be called right away if InitialNotification flag is set. The attached patch fixes the issue. Far Cry 5 online mode also requires BCryptSecretAgreement(ECDH) and BCryptDeriveKey(KDF_HASH, SHA1 hash) implementation, which is Bug #47699. -- 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.

1 7

[Bug 54574] New: Ubisoft Connect fails to initialize - Window doesn't show
by WineHQ Bugzilla Nov. 29, 2023

Nov. 29, 2023

https://bugs.winehq.org/show_bug.cgi?id=54574 Bug ID: 54574 Summary: Ubisoft Connect fails to initialize - Window doesn't show Product: Wine Version: 8.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maiktapwagner(a)aol.com Distribution: --- Created attachment 74117 --> https://bugs.winehq.org/attachment.cgi?id=74117 Console output (wine-8.2 on Slackware64/Multilib) Hello everyone, I am having problems launching UbisoftConnect.exe - it installs fine after "winetricks corefonts" is run but doesn't start up. All I get is a blank window and I can't log in as the login screen doesn't show. -- 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.

1 3

[Bug 54102] New: GPU Caps Viewer does not report any OpenCL devices starting with version 7.21 / 7.22
by WineHQ Bugzilla Nov. 29, 2023

Nov. 29, 2023

https://bugs.winehq.org/show_bug.cgi?id=54102 Bug ID: 54102 Summary: GPU Caps Viewer does not report any OpenCL devices starting with version 7.21 / 7.22 Product: Wine Version: 7.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: danielyhwong(a)gmail.com Distribution: --- This is the exact same issue with ticket 52389 in which GPU Caps viewer no longer report CUDA support. This happens starting with version 7.21 and 7.22. Revert back to version 7.20 resolves this issue. In addition, I also reported exactly the same problem to Julliard on Jan 17, in which I highlighted that starting with WINE 7.0-RC6 the problem goes away. I include this info here for completeness. If more info is required, please let me know, I can run tests and provide results here. -- 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.

1 15

[Bug 53556] New: winealsa.drv segfaults on process exit
by WineHQ Bugzilla Nov. 28, 2023

Nov. 28, 2023

https://bugs.winehq.org/show_bug.cgi?id=53556 Bug ID: 53556 Summary: winealsa.drv segfaults on process exit Product: Wine Version: 7.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: brendan(a)redmandi.com Distribution: --- Created attachment 72919 --> https://bugs.winehq.org/attachment.cgi?id=72919 Adds test to kernelbase_test.exe sync I get a segfault on process exit whenever the winealsa.drv is loaded. I can recreate this by running the winmm_test.exe midi test for example. I've also attached a patch that adds a test to kernelbase_test.exe (under the 'sync' tests) that recreates this issue. It's recreated in this patch without the process exit (thread termination is enough). Here's the stacktrace for the winealsa.drv thread at the beginning of signal_exit_thread (not long after SIGQUIT is signaled): #0 0x00007ffff7cee3ce in signal_exit_thread () #1 0x00007ffff7d0d25b in abort_thread (status=status(a)entry=0) at ../../include/winnt.h:2246 #2 0x00007ffff7cf12e8 in quit_handler (signal=<optimised out>, siginfo=<optimised out>, ucontext=<optimised out>) at ../../dlls/ntdll/unix/signal_x86_64.c:2861 #3 <signal handler called> #4 0x00007ffff7e0a195 in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x7ffff5aa2528 <notify_read_cond+40>) at ./nptl/futex-internal.c:57 #5 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x7ffff5aa2528 <notify_read_cond+40>) at ./nptl/futex-internal.c:87 #6 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word(a)entry=0x7ffff5aa2528 <notify_read_cond+40>, expected=expected(a)entry=0, clockid=clockid(a)entry=0, abstime=abstime(a)entry=0x0, private=private(a)entry=0) at ./nptl/futex-internal.c:139 #7 0x00007ffff7e0cac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7ffff5aa2540 <notify_mutex>, cond=0x7ffff5aa2500 <notify_read_cond>) at ./nptl/pthread_cond_wait.c:503 #8 ___pthread_cond_wait (cond=cond(a)entry=0x7ffff5aa2500 <notify_read_cond>, mutex=mutex(a)entry=0x7ffff5aa2540 <notify_mutex>) at ./nptl/pthread_cond_wait.c:627 #9 0x00007ffff5a99a67 in midi_notify_wait (args=0x23cfdd0) at ../../dlls/winealsa.drv/alsamidi.c:1512 #10 0x00007ffff7cd7f13 in __wine_unix_call (handle=<optimised out>, code=<optimised out>, args=0x7ffff5aa2528 <notify_read_cond+40>) at ../../dlls/ntdll/unix/loader.c:1362 #11 0x00007ffff7cee565 in __wine_syscall_dispatcher () #12 0x00000000024cf640 in ?? () #13 0x0000000000000019 in ?? () #14 0x00007ffff7e0d850 in ?? () at ./nptl/pthread_create.c:321 #15 0x00007ffff7cee3cc in signal_start_thread () #16 0x0000000000000000 in ?? () Before the call to __GI___futex_abstimed_wait_cancelable64 (made from frame 7), the following line of code is executed: https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_cond_wait.c;h… __pthread_cleanup_push (&buffer, __condvar_cleanup_waiting, &cbuffer); This appears to push some cleanup code on to a cleanup stack that glibc later attempts to use during thread termination. However, the buffer and cbuffer structs are allocated on the threads stack. Exploring frame 7, we can get the memory address for the buffer struct (0x24ce870): (gdb) f 7 #7 0x00007ffff7e0cac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7ffff5aa2540 <notify_mutex>, cond=0x7ffff5aa2500 <notify_read_cond>) at ./nptl/pthread_cond_wait.c:503 warning: Source file is more recent than executable. 503 err = __futex_abstimed_wait_cancelable64 ( (gdb) p &buffer $1 = (struct _pthread_cleanup_buffer *) 0x24ce870 I then step forward 4 instructions: (gdb) si 0x00007ffff7cee3d5 in signal_exit_thread () 1: x/i $rip => 0x7ffff7cee3d5 <signal_exit_thread+9>: test %rcx,%rcx (gdb) 0x00007ffff7cee3d8 in signal_exit_thread () 1: x/i $rip => 0x7ffff7cee3d8 <signal_exit_thread+12>: jne 0x7ffff7cee3dc <signal_exit_thread+16> (gdb) 0x00007ffff7cee3dc in signal_exit_thread () 1: x/i $rip => 0x7ffff7cee3dc <signal_exit_thread+16>: mov %rcx,%rsp (gdb) 0x00007ffff7cee3df in signal_exit_thread () 1: x/i $rip => 0x7ffff7cee3df <signal_exit_thread+19>: call *%rsi (gdb) bt #0 0x00007ffff7cee3df in signal_exit_thread () #1 0x00007ffff7d0a1f0 in start_thread (teb=0x67fd0000) at ../../dlls/ntdll/unix/thread.c:1070 #2 0x00007ffff7e0db43 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442 #3 0x00007ffff7e9fa00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 (gdb) p $rsp $2 = (void *) 0x24cee00 And now the $rsp register is updated (to 0x24cee00), but it's to the right of the buffer struct. 0x24cee00 - 0x24ce870 = 0x590 (1424 bytes). So once the stack expands 1424 bytes (to the left), this buffer struct is overwritten. I add a watch to the buffer structs memory address and continue: (gdb) watch ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine (gdb) c Continuing. Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine Old value = (void (*)(void *)) 0x7ffff7e0c7a0 <__condvar_cleanup_waiting> New value = (void (*)(void *)) 0x7ffff7e16330 <unwind_stop> 0x00007ffff7fc2426 in __GI__dl_find_object (pc1=0x7ffff51663e9 <_Unwind_ForcedUnwind+57>, result=0x24ce8d0) at ./elf/dl-find_object.c:363 363 if (__glibc_unlikely (_dlfo_main.map_end == 0)) 1: x/i $rip => 0x7ffff7fc2426 <__GI__dl_find_object+6>: push %r13 (gdb) Continuing. Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine Old value = (void (*)(void *)) 0x7ffff7e16330 <unwind_stop> New value = (void (*)(void *)) 0x7ffff51663e9 <_Unwind_ForcedUnwind+57> 0x00007ffff5166c91 in get_cie_encoding (cie=0x7ffff516a1b8) at ../../../src/libgcc/unwind-dw2-fde.c:299 299 aug = cie->augmentation; 1: x/i $rip => 0x7ffff5166c91 <get_cie_encoding+1>: mov %rdi,%rbp (gdb) Continuing. Thread 2 "winmm_test.exe" hit Hardware watchpoint 3: ((struct _pthread_cleanup_buffer *) 0x24ce870)->__routine Old value = (void (*)(void *)) 0x7ffff51663e9 <_Unwind_ForcedUnwind+57> New value = (void (*)(void *)) 0x24ce890 0x00007ffff516584c in uw_update_context_1 (context=0x24ceb90, fs=0x24ce9d0) at ../../../src/libgcc/unwind-dw2.c:1454 1454 switch (fs->regs.reg[i].how) 1: x/i $rip => 0x7ffff516584c <uw_update_context_1+492>: lea 0x4209(%rip),%rbp # 0x7ffff5169a5c (gdb) c Continuing. It actually gets updated a few times, but the last update is to an invalid executable address (0x24ce890); which ultimately leads to the segfault: Thread 2 "winmm_test.exe" received signal SIGSEGV, Segmentation fault. 0x00000000024ce890 in ?? () 1: x/i $rip => 0x24ce890: rex.WXB add %al,(%r8) 1: x/i $rip => 0x24ce890: rex.WXB add %al,(%r8) -- 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.

1 5