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

[Bug 15906] New: EnumFonts returns each font multiple times
by wine-bugs＠winehq.org May 18, 2021

May 18, 2021

http://bugs.winehq.org/show_bug.cgi?id=15906 Summary: EnumFonts returns each font multiple times Product: Wine Version: 1.1.5 Platform: PC-x86-64 URL: http://msdn.microsoft.com/en- us/library/ms533964(VS.85).aspx OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: goeran(a)uddeborg.se Created an attachment (id=17078) --> (http://bugs.winehq.org/attachment.cgi?id=17078) Test program executing EnumFonts() According to the documentation (see URL) the EnumFonts function returns one (random) font of each available typeface. The Wine implementation returns each typeface many times. As a test case I installed the typeface "Signet Roundhand" and ran the attached test program. Under indows it returns "Signet Roundhand" once. Under wine it returns it three times, with different values for lfCharSet and tmCharSet. I also copied the Arial font files from Windows (arial.ttf, ariali.ttf, arialbd.ttf, and arialbi.ttf) to my $HOME/.fonts directory. Under Windows, Arial is returned once with the test program. Under Wine it is returned ten(!) times. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 17

[Bug 14350] New: SetClassLongW() to subclass window EDIT control Problem
by wine-bugs＠winehq.org May 18, 2021

May 18, 2021

http://bugs.winehq.org/show_bug.cgi?id=14350 Summary: SetClassLongW() to subclass window EDIT control Problem Product: Wine Version: 1.0.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: hongbo(a)njstar.com CC: hongbo(a)njstar.com Created an attachment (id=14649) --> (http://bugs.winehq.org/attachment.cgi?id=14649) MSVC6 MFC test project with exe in debug dir Summary: SetClassLongW(hEditWnd, GCL_WNDPROC, (DWORD)EditWndProc) behave different on WINE 1.0 from Windows. Any EDIT window created after will be ANSI window on Windows, but Unicode Windows on Wine. How To Repeat: In the attached VC6 MFC ANSI App project, SetClassLongW is called in ------------------------------------------------------------------- static WNDPROC lpfnOldEditWndProc=NULL; LONG FAR PASCAL EditWndProc(HWND hWnd, WORD Message, WORD wParam, LONG lParam) { return CallWindowProcW((WNDPROC)lpfnOldEditWndProc, hWnd, Message, wParam,lParam); } int CDialogTestView::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CView::OnCreate(lpCreateStruct) == -1) return -1; HWND hEditWnd1 = CreateWindowEx(0,"EDIT", "E1",WS_POPUP,0, 0, 1, 1,NULL,NULL,NULL,NULL); lpfnOldEditWndProc =(WNDPROC)SetClassLongW(hEditWnd1, GCL_WNDPROC, (DWORD)EditWndProc); // TODO: Add your specialized creation code here return 0; } ------------------------------------------------------------------- There is a EDIT control on the About dialogbox, when click 'OK' on window the program report the Edit Box is NOT unicode Window. But Under Wine 1.0, It says 'the Edit Box IS unicode Window'. To Test: run the EXE in debug folder, Help - About DialogTest - click 'OK'. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 18

[Bug 12891] New: ntdll: exception.ok test fails in PC-BSD but not Linux
by wine-bugs＠winehq.org May 18, 2021

May 18, 2021

http://bugs.winehq.org/show_bug.cgi?id=12891 Summary: ntdll: exception.ok test fails in PC-BSD but not Linux Product: Wine Version: 0.9.60 Platform: PC OS/Version: FreeBSD Status: NEW Keywords: testcase Severity: minor Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=12597) --> (http://bugs.winehq.org/attachment.cgi?id=12597) +relay,+seh,+ntdll in git exception.c:602: Test failed: expected 4 exceptions, got 0 fixme:seh:fpe_handler untested SIMD exception: 0. Might not work correctly *** Error code 1 +relay,+seh,+ntdll log attached -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 50833] New: Being able to use Windows 10 theme
by WineHQ Bugzilla May 17, 2021

May 17, 2021

https://bugs.winehq.org/show_bug.cgi?id=50833 Bug ID: 50833 Summary: Being able to use Windows 10 theme Product: Wine Version: 5.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: toadfield(a)tutanota.com Distribution: --- The windows xp theme doesn't work for any program,but the windows 10 theme could. -- 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 36282] New: valgrind shows an unitialized write in ieframe/tests/ie.c
by wine-bugs＠winehq.org May 16, 2021

May 16, 2021

https://bugs.winehq.org/show_bug.cgi?id=36282 Bug ID: 36282 Summary: valgrind shows an unitialized write in ieframe/tests/ie.c Product: Wine Version: 1.3.13 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: ieframe Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==16468== Thread 6: ==16468== Syscall param write(buf) points to uninitialised byte(s) ==16468== at 0x4EA8262B: ??? (in /usr/lib/libpthread-2.18.so) ==16468== by 0x7BC46BB8: NtWriteFile (file.c:1073) ==16468== by 0x7B83E0AA: WriteFile (file.c:563) ==16468== by 0x5A01BB8: rpcrt4_conn_np_write (rpc_transport.c:444) ==16468== by 0x59F6B27: rpcrt4_conn_write (rpc_binding.h:189) ==16468== by 0x59F8AA9: RPCRT4_SendWithAuth (rpc_message.c:849) ==16468== by 0x59F9BA0: RPCRT4_Send (rpc_message.c:1245) ==16468== by 0x59FCD02: process_request_packet (rpc_server.c:464) ==16468== by 0x59FCF82: RPCRT4_process_packet (rpc_server.c:519) ==16468== by 0x59FD115: RPCRT4_worker_thread (rpc_server.c:541) ==16468== by 0x7BC909EA: worker_thread_proc (threadpool.c:110) ==16468== by 0x7BC87087: ??? (signal_i386.c:2571) ==16468== by 0x7BC870D0: call_thread_func (signal_i386.c:2630) ==16468== by 0x7BC87065: ??? (signal_i386.c:2571) ==16468== by 0x7BC8E4B0: start_thread (thread.c:428) ==16468== by 0x4EA7BD89: start_thread (in /usr/lib/libpthread-2.18.so) ==16468== by 0x4E95CA0D: clone (in /usr/lib/libc-2.18.so) ==16468== Address 0x47f9cf4 is 44 bytes inside a recently re-allocated block of size 92 alloc'd ==16468== at 0x7BC4C735: notify_alloc (heap.c:255) ==16468== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==16468== by 0x59F88E9: RPCRT4_SendWithAuth (rpc_message.c:808) ==16468== by 0x59F9BA0: RPCRT4_Send (rpc_message.c:1245) ==16468== by 0x59FCD02: process_request_packet (rpc_server.c:464) ==16468== by 0x59FCF82: RPCRT4_process_packet (rpc_server.c:519) ==16468== by 0x59FD115: RPCRT4_worker_thread (rpc_server.c:541) ==16468== by 0x7BC909EA: worker_thread_proc (threadpool.c:110) ==16468== by 0x7BC87087: ??? (signal_i386.c:2571) ==16468== by 0x7BC870D0: call_thread_func (signal_i386.c:2630) ==16468== by 0x7BC87065: ??? (signal_i386.c:2571) ==16468== by 0x7BC8E4B0: start_thread (thread.c:428) ==16468== by 0x4EA7BD89: start_thread (in /usr/lib/libpthread-2.18.so) ==16468== by 0x4E95CA0D: clone (in /usr/lib/libc-2.18.so) ==16468== Uninitialised value was created by a client request ==16468== at 0x7BC4C52C: mark_block_uninitialized (heap.c:209) ==16468== by 0x7BC4C697: initialize_block (heap.c:240) ==16468== by 0x7BC50FA3: RtlAllocateHeap (heap.c:1717) ==16468== by 0x501E635: IMalloc_fnAlloc (ifs.c:186) ==16468== by 0x501EF50: CoTaskMemAlloc (objidl.h:1236) ==16468== by 0x505C935: RemUnknown_RemQueryInterface (stubmanager.c:690) ==16468== by 0x50661C6: IRemUnknown_RemQueryInterface_Stub (dcom_p.c:369) ==16468== by 0x59CA5BF: CStdStubBuffer_Invoke (cstub.c:477) ==16468== by 0x503D280: RPC_ExecuteCall (objidl.h:9086) ==16468== by 0x4FFC1ED: apartment_wndproc (compobj.c:1460) ==16468== by 0x548C509: ??? (winproc.c:173) ==16468== by 0x548C67E: call_window_proc (winproc.c:244) ==16468== by 0x548E817: WINPROC_call_window (winproc.c:900) ==16468== by 0x544FBE4: DispatchMessageW (message.c:4019) ==16468== by 0x4793F60: IEWinMain (iexplore.c:1061) ==16468== by 0x472CA34: wWinMain (main.c:84) ==16468== by 0x472CD21: wmain (exe_wmain.c:51) ==16468== by 0x472CBFC: __wine_spec_exe_wentry (exe_wentry.c:36) ==16468== by 0x7B864247: ??? (process.c:1045) ==16468== by 0x7B864394: start_process (process.c:1097) ==16468== -- 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 3

[Bug 28831] New: secur32/tests/schannel.ok: occasional uninitialised memory read in _gnutls_recv_int() in test_communication()?
by wine-bugs＠winehq.org May 16, 2021

May 16, 2021

http://bugs.winehq.org/show_bug.cgi?id=28831 Bug #: 28831 Summary: secur32/tests/schannel.ok: occasional uninitialised memory read in _gnutls_recv_int() in test_communication()? Product: Wine Version: 1.3.30 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: secur32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Classification: Unclassified I don't see this on every run, but sometimes Valgrind complains: Conditional jump or move depends on uninitialised value(s) at _gnutls_recv_int (in /usr/lib/i386-linux-gnu/libgnutls.so.26.16.14) by ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.16.14) by ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.16.14) by ??? (in /usr/lib/i386-linux-gnu/libgnutls.so.26.16.14) by schan_InitializeSecurityContextW (schannel.c:728) by schan_InitializeSecurityContextA (schannel.c:775) by InitializeSecurityContextA (wrapper.c:282) by test_communication (schannel.c:644) by func_schannel (schannel.c:773) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a client request by mark_block_uninitialized (heap.c:208) by initialize_block (heap.c:239) by RtlAllocateHeap (heap.c:1703) by init_buffers (schannel.c:496) by test_communication (schannel.c:633) by func_schannel (schannel.c:773) by run_test (test.h:556) by main (test.h:624) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 4

[Bug 51066] New: Fallout New Vegas GOG Edition (1.4.0.525 GOG): Music looping too early
by WineHQ Bugzilla May 16, 2021

May 16, 2021

https://bugs.winehq.org/show_bug.cgi?id=51066 Bug ID: 51066 Summary: Fallout New Vegas GOG Edition (1.4.0.525 GOG): Music looping too early Product: Wine Version: 6.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: wineburn(a)protonmail.com Distribution: --- When playing the GOG version of Fallout:NV, the music loops abruptly every appox. 20 seconds. This affects both the ambient music and the radio. I have tried: - installing the dsound, directshow and quartz verbs - disabling all mods, including official DLCs - Using a completely vanilla installation (this happens in both when using the exe directly and NVSE/ModOrganizer) I am using wine 6.7 staging. EXE SHA1: 946d2eaba04a75ff361b8617c7632b49f1ede9d3 FalloutNV.exe -- 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 51055] New: winecfg: Redirection stdout stream
by WineHQ Bugzilla May 16, 2021

May 16, 2021

https://bugs.winehq.org/show_bug.cgi?id=51055 Bug ID: 51055 Summary: winecfg: Redirection stdout stream Product: Wine Version: 5.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: iroalexis(a)outlook.fr Distribution: --- Since Wine 5.18, the stdout stream is completly "ignore/redirect" (I don't know if it is the good words for describe this behavior) in the main function of winecfg.c. This means that the `winecfg -v` and/or `winecfg -?` commands do not display anything I bisect for found the wrong commit, but I did not succeed. I found only a commits window. It's located between a014f413d6719cce883cafe9f40ec0b6468de097 and b16f552e195048f434d486a084fad0fa3afcf712. Before a014f413d6719cce883cafe9f40ec0b6468de097, winecfg displays well the different information of the -? and -v commands. But from b16f552e195048f434d486a084fad0fa3afcf712, this commands don't display nothing. -- 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 50973] New: winedbg --gdb exits immediately
by WineHQ Bugzilla May 16, 2021

May 16, 2021

https://bugs.winehq.org/show_bug.cgi?id=50973 Bug ID: 50973 Summary: winedbg --gdb exits immediately Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winedbg Assignee: wine-bugs(a)winehq.org Reporter: grandchild(a)mailbox.org Distribution: --- Hi, similar to https://bugs.winehq.org/show_bug.cgi?id=50117 but from version 6.5 onwards, "winedbg --gdb" exits immediately and runs the program, instead of showing the gdb shell, which used to stop after loading but before running the program. Version 6.4 does not have this issue. I've git-bisected it down to this commit: 28fe84da45bea7de56539b50eac8ebcec54342de Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Mar 24 10:53:53 2021 +0100 ntdll: Load the main image from the Unix side. Unfortunately this is a massive commit, and I can't right now put in the time to dig deeper into what might be causing the gdb mode to exit early. Also it doesn't revert easy on the latest version, 6.6. Maybe someone has a quicker understanding of where to look within that change. If not I can start digging deeper myself. To reproduce: winedbg --gdb notepad.exe OS info: latest Archlinux x86-64 Regards, Jakob -- 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 11

[Bug 50879] New: STDOUT output lost from Winelib applications in Wine 6.5 because of start.exe
by WineHQ Bugzilla May 16, 2021

May 16, 2021

https://bugs.winehq.org/show_bug.cgi?id=50879 Bug ID: 50879 Summary: STDOUT output lost from Winelib applications in Wine 6.5 because of start.exe Product: Wine Version: 6.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: mail(a)robbertvanderhelm.nl Distribution: --- (split from bug 50869, see there for some other related issues) When launching Winelib applications in Wine 6.5, all output written to STDOUT gets lost. I tested this with a simple C++ file compiled with wineg++ that tries to print some text using both `printf()` and `std::cout`. Printing to STDERR using `std::cerr` still works fine. -- 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