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

[Bug 27708] New: GetThreadSelectorEntry fails
by wine-bugs＠winehq.org March 1, 2020

March 1, 2020

http://bugs.winehq.org/show_bug.cgi?id=27708 Summary: GetThreadSelectorEntry fails Product: Wine Version: 1.2.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: nitsuja-(a)hotmail.com Created an attachment (id=35459) --> (http://bugs.winehq.org/attachment.cgi?id=35459) binary (and source code) of the test case When a program calls GetThreadSelectorEntry after creating a process, it fails in Wine (returns FALSE and sets lasterror to 5), but succeeds in Windows. This is a problem for a program I made which needs this function to work, so I've boiled it down to a tiny test case which still fails in the same way, and is attached. When run on Windows, this exe brings up a messagebox saying "ALL OK", but when run on Wine, it says "ERROR: GetThreadSelectorEntry failed". Here's the source code: #define WIN32_LEAN_AND_MEAN #define _WIN32_WINNT 0x0500 #include <windows.h> void AssertSuccess(BOOL success, const char* errorMessage); int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) { // it doesn't matter which exe I start, so for this example I use the current exe path CHAR filename[MAX_PATH]; GetModuleFileName(NULL, filename, MAX_PATH); STARTUPINFO startupInfo = {sizeof(STARTUPINFO)}; PROCESS_INFORMATION processInfo = {}; BOOL success = CreateProcess(filename, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED | DEBUG_PROCESS, NULL, NULL, &startupInfo, &processInfo); AssertSuccess(success, "ERROR: CreateProcess failed.\n"); HANDLE hThread = processInfo.hThread; CONTEXT context; context.ContextFlags = CONTEXT_SEGMENTS; success = GetThreadContext(hThread, &context); AssertSuccess(success, "ERROR: GetThreadContext failed.\n"); LDT_ENTRY ldtEntry; success = GetThreadSelectorEntry(hThread, context.SegFs, &ldtEntry); AssertSuccess(success, "ERROR: GetThreadSelectorEntry failed.\n"); if(success) MessageBox(NULL, "ALL OK.", "DONE", MB_ICONASTERISK); return success ? 0 : -1; } void AssertSuccess(BOOL success, const char* errorMessage) { if(!success) MessageBox(NULL, errorMessage, "ERROR", MB_ICONERROR); } -- 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 9

[Bug 48692] New: MFC CFileDialog with bVistaStyle == true not displaying content on osx64
by WineHQ Bugzilla March 1, 2020

March 1, 2020

https://bugs.winehq.org/show_bug.cgi?id=48692 Bug ID: 48692 Summary: MFC CFileDialog with bVistaStyle == true not displaying content on osx64 Product: Wine Version: 5.0-rc6 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: reinhold.hoffmann(a)hotmail.com Created attachment 66560 --> https://bugs.winehq.org/attachment.cgi?id=66560 Demos to demonstarte the issue of CFileDialog with bVistaStyle == true not displaying content on osx64 With portable-winehq-devel-5.0-osx64.tar.gz on Mac the MFC call CFileDialog with parameter bVistaStyle == true does not display the directory content of an x64 app. The parameter bVistaStyle == false works fine. The same app as a Win32 app with portable-winehq-devel-5.0-osx.tar.gz works fine. It looks as if this issue is just on a Mac. To demonstrate the issue please find demos in the attached zip file: (1) Wine_Bug_CFileDialog_bVistaStyle_TRUE_x64.exe This app shows the issue on portable-winehq-devel-5.0-osx64.tar.gz (2) Wine_Bug_CFileDialog_bVistaStyle_FALSE_x64.exe This app is fine and corretly shows the content on portable-winehq-devel-5.0-osx64.tar.gz (3) Wine_Bug_CFileDialog_bVistaStyle_TRUE_x86.exe In contraty to (1) this runs fine on portable-winehq-devel-5.0-osx.tar.gz (4) The demo app in source code as a Visual Studio project -- 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 0

[Bug 44141] New: Divinity: Original Sin 2 massive slowdown with shadows enabled
by wine-bugs＠winehq.org March 1, 2020

March 1, 2020

https://bugs.winehq.org/show_bug.cgi?id=44141 Bug ID: 44141 Summary: Divinity: Original Sin 2 massive slowdown with shadows enabled Product: Wine Version: 2.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: r9shackleford(a)gmail.com Distribution: --- Created attachment 59889 --> https://bugs.winehq.org/attachment.cgi?id=59889 Log file running Divinity:Original Sin 2 with shadows enabled. Enabling shadows fills the log with: fixme:d3d:wined3d_debug_callback 0x2377a6a0: "Program undefined behavior warning: Sampler object 24 has depth compare enabled but is bound to a non-depth texture, and used by a program that samples it with a shadow sampler. This is undefined behavior.". Driver is Nvidia Proprietary, no idea what other drivers say with shadows enabled. It goes away when shadows are disabled, and framerate returns to normal. Possibly related log messages that seem unrelated to shadows being enabled/disabled: fixme:d3d11:shdr_handler Unhandled chunk "RDEF". fixme:d3d11:shdr_handler Unhandled chunk "STAT". fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x800000c2. fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x00155543. fixme:d3d11:wined3d_depth_stencil_view_desc_from_d3d11 Unhandled depth stencil view flags 0x3. Clean wine directory, absolutely no dll overrides. Attached is a log of running the game to the menu screen with shadows enabled. The game menu screen has 3D rendering which triggers the bug. A log without shadows is essentially identical sans the wined3d_debug_callback line spammed as stated above. -- 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 5

[Bug 44257] New: Divinity: Original Sin 2: Audio via pulseaudio has popping/crackling in music
by wine-bugs＠winehq.org March 1, 2020

March 1, 2020

https://bugs.winehq.org/show_bug.cgi?id=44257 Bug ID: 44257 Summary: Divinity: Original Sin 2: Audio via pulseaudio has popping/crackling in music Product: Wine Version: 2.21 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lucianposton(a)gmail.com Distribution: --- The music on the start screen has minor crackling/popping sounds with pulseaudio. This repros on both card 0 device 0 and card 1 device 3 listed below. I was able to workaround the issue by disabling timer-based scheduling via the following setting in /etc/pulse/default.pa: load-module module-udev-detect tsched=0 pulseaudio-11.1 aplay --list-devices **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC889 Analog [ALC889 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: ALC889 Digital [ALC889 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: USB [Scarlett 2i4 USB], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 -- 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