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

[Bug 33625] New: javascript typed arrays needed for emscripten
by wine-bugs＠winehq.org Nov. 1, 2020

Nov. 1, 2020

http://bugs.winehq.org/show_bug.cgi?id=33625 Bug #: 33625 Summary: javascript typed arrays needed for emscripten Product: Wine Version: 1.5.23 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: jscript AssignedTo: wine-bugs(a)winehq.org ReportedBy: wine.dev(a)web.de Classification: Unclassified Created attachment 44508 --> http://bugs.winehq.org/attachment.cgi?id=44508 screenshot This emscripten-qt demo failed to load: http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt-examples/scrib… -- By by ... Detlef -- 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 6

[Bug 47208] New: Wine-staging's "winebuild-Fake_Dlls" cause Office 2019 to say "IOPL not enabled"
by wine-bugs＠winehq.org Oct. 30, 2020

Oct. 30, 2020

https://bugs.winehq.org/show_bug.cgi?id=47208 Bug ID: 47208 Summary: Wine-staging's "winebuild-Fake_Dlls" cause Office 2019 to say "IOPL not enabled" Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: peathot(a)hotmail.com CC: leslie_alistair(a)hotmail.com, michael(a)fds-team.de, z.figura12(a)gmail.com Distribution: --- Created attachment 64469 --> https://bugs.winehq.org/attachment.cgi?id=64469 Console output before the offending patch is applied Microsoft Word 2019 (version 1904, build 11601.20204, installed via Office 365) will not start if patchset "winebuild-Fake_Dlls" is applied to wine source. A popup saying "IOPL not enabled" will appear after starting up for a while. To be exact, the patch that causes the problem is the patch "0003-winebuild-Generate-syscall-thunks-for-ntdll-exports.patch". This is found out by applying patches with "patches/patchinstall.sh DESTDIR=../wine-source --backend=git-am --all" then doing bisect between master & staging. By checking out this patch's parent commit, Microsoft Word 2019 starts successfully. [1] I've tried to exclude this patchset (and patchsets that depend on it) while applying patches using [2]. By doing that, Microsoft Word starts successfully. Wine's commit is "99114803b80f6e687f1d4ed11e0808b821cdbf22", while Wine-staging's commit is "6ce73c283d4953e348ef87e237c4d29b933abadb". The OS is Xubuntu 18.04. The machine is Mac Mini early 2009 with Nvidia Geforce 9400m. The graphic stack is mesa + nouveau (i.e. Nvidia proprietary driver is not installed). The MS Office is installed using the instructions from [3]. Also, CSMT is disabled due to nouveau's problem with multithreaded OpenGL (see #46707). [1] However, this means all patches which appear later isn't applied yet. The exact patch application order can be seen in the attachment. [2] ./patches/patchinstall.sh DESTDIR=../wine-source/ --backend=git-am --all -W winebuild-Fake_Dlls -W ntdll-NtContinue -W ntdll-RtlCreateUserThread -W eventfd_synchronization -W server-Desktop_Refcount -W ws2_32-TransmitFile -W kernel32-K32GetPerformanceInfo [3] https://appdb.winehq.org/objectManager.php?sClass=version&iId=35527&iTestin… -- 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 23

[Bug 22808] New: Selected rows in WinRar flicker while selecting by dragging rectangle
by wine-bugs＠winehq.org Oct. 29, 2020

Oct. 29, 2020

http://bugs.winehq.org/show_bug.cgi?id=22808 Summary: Selected rows in WinRar flicker while selecting by dragging rectangle Product: Wine Version: 1.1.43 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: b7.10110111(a)gmail.com Steps to reproduce: open an archive with several files using WinRar, then try to select some files using mouse selection rectangle (dunno how this mechanism is named). The rows already selected flicker when mouse is moved. -- 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 38693] New: crash of MS Money3
by wine-bugs＠winehq.org Oct. 26, 2020

Oct. 26, 2020

https://bugs.winehq.org/show_bug.cgi?id=38693 Bug ID: 38693 Summary: crash of MS Money3 Product: Wine Version: 1.4.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fbmines(a)gmail.com Distribution: --- Created attachment 51616 --> https://bugs.winehq.org/attachment.cgi?id=51616 bug backtrace crash of Microsoft Money v3 in opening some accounts, while so far working well. -- 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 15

[Bug 37516] New: VideoReDo TVSuite H.264 crashes on loading video when using VMR7
by wine-bugs＠winehq.org Oct. 26, 2020

Oct. 26, 2020

https://bugs.winehq.org/show_bug.cgi?id=37516 Bug ID: 37516 Summary: VideoReDo TVSuite H.264 crashes on loading video when using VMR7 Product: Wine Version: 1.7.30 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: gordon.lack(a)dsl.pipex.com Distribution: --- Created attachment 49928 --> https://bugs.winehq.org/attachment.cgi?id=49928 Crash log produced by wine VideoReDo TVSuite H.264 (http://www.videoredo.com/en/ProductTVS.htm) starts up OK. Under Tools/Options/Playback Devices you can select VMR7 as the Video Driver (FYI: DirectX is also listed there, but it isn't supported any more, and actually used VMR7 as well - the option is going away). This determines the driver used when running the editing page. If you now load a video (mpeg, or h.264) into the program it will crash. -- 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 15

[Bug 17073] New: Star Trek Generations fails to display
by wine-bugs＠winehq.org Oct. 25, 2020

Oct. 25, 2020

http://bugs.winehq.org/show_bug.cgi?id=17073 Summary: Star Trek Generations fails to display Product: Wine Version: 1.1.13 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: Rincebrain(a)gmail.com On attempting to run Star Trek: Generations in Wine, I receive the following output, the cursor renders correctly, and an [almost] black screen (the top ~80 pixels of the screen display something non-black, in fullscreen mode - in windowed mode, nothing is visible) (see linked screenshot): $ wine sgens.exe fixme:ddraw:VGA_ioport_in Unsupported index, VGA crt controller register 0x3b4/0x3d4: 0x0f fixme:ddraw:VGA_ioport_out Unsupported index, VGA crt controller register 0x3b4/0x3d4: 0x0f (value 0x2a) fixme:ddraw:VGA_ioport_in Unsupported index, VGA crt controller register 0x3b4/0x3d4: 0x0f fixme:ddraw:VGA_ioport_out Unsupported index, VGA crt controller register 0x3b4/0x3d4: 0x0f (value 0xff) fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers fixme:win:EnumDisplayDevicesW ((null),0,0x32f3c8,0x00000000), stub! fixme:ddraw:IDirectDrawImpl_WaitForVerticalBlank (0x13d780)->(1,(nil)): Stub fixme:ddraw:IDirectDrawImpl_GetScanLine (0x13d780)->(0x32f980): Semi-Stub fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8 err:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow (0x1440f0): Want to change the window parameters of HWND 0x20034, but another style is stored for restoration afterwards err:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow (0x1440f0): Want to change the window parameters of HWND 0x20034, but another style is stored for restoration afterwards fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 err:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow (0x1440f0): Want to change the window parameters of HWND 0x20034, but another style is stored for restoration afterwards err:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow (0x1440f0): Want to change the window parameters of HWND 0x20034, but another style is stored for restoration afterwards err:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow (0x1440f0): Want to change the window parameters of HWND 0x20034, but another style is stored for restoration afterwards Tested with wine-1.1.12-777-g6d0a0fb and wine-1.1.12-829-g0b8faac. Must be run with Windows 95/98/ME - game requires Win95 or above, and running with Win2K or above results in a crash (which I'm filing). -- 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 26

[Bug 26803] New: file open dialog: slow when selecting many files
by wine-bugs＠winehq.org Oct. 25, 2020

Oct. 25, 2020

http://bugs.winehq.org/show_bug.cgi?id=26803 Summary: file open dialog: slow when selecting many files Product: Wine Version: 1.3.17 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: pa78(a)gmx.net The bug: The more files I select in the file open diaolg the longer it takes until the files are actually selected and I can click the open button. This bug is not about the load time of the program but the time the files get selected in the file open dialog. Hints to reproduce: Selecting one file in the dialog window happen instantly. Pressing shift and selecting 3 files also is very fast. Pressing shift and selecting 10 files takes up to 1 second. Pressing shift and selecting 30 files already takes 10 seconds. Pressing shift and selecting 50 files already takes 40 seconds. Pressing shift and selecting 100 files already takes 270 seconds (equals 4:30 min). As you can see times are raising nearly exponential. In Windows/Gnome/Kde/... it doesn't matter how many files are selected/deselected. It takes always the same time. Additional notes: My cpu is a 3 year old dualcore 1.86 ghz. If you can't reproduce this times because your machine is much faster just select more files because time is raising nearly exponential. This is an old bug (probably pre wine 1.0) and still (wine 1.3.17) very annoying to me because sometimes I have to open a few hundret files. I think this was never implemented well. Just so far that it is possible to open one or a few files. -- 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 23

[Bug 45377] New: StreetFighter V Arcade Edition (Steam) custom protection scheme fails to validate in-memory 'ntdll.dll' PE header against on-disk fake-dll
by wine-bugs＠winehq.org Oct. 24, 2020

Oct. 24, 2020

https://bugs.winehq.org/show_bug.cgi?id=45377 Bug ID: 45377 Summary: StreetFighter V Arcade Edition (Steam) custom protection scheme fails to validate in-memory 'ntdll.dll' PE header against on-disk fake-dll Product: Wine Version: 3.11 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation of bug 45349 It's a similar problem domain as bug 15437 ("Multiple programs using madCodeHook crash (in-memory PE image of Wine builtins vs. ELF image on disk)") but unlike that one it can't be worked around by removing the placeholder/fake dll. Trace log doesn't reveal much. It has to be debugged with 64-bit debuggers that are very unstable/fragile due to various Wine bugs #debugception NOTE: relay thunks don't work here. --- snip --- $ WINEDEBUG=+seh,+server,+ntdll wine ./StreetFighterV.exe >>log.txt 2>&1 ... 002e:trace:ntdll:FILE_CreateFile handle=0x5ff768 access=80100000 name=L"\\??\\C:\\windows\\system32\\ntdll.dll" objattr=00000040 root=(nil) sec=(nil) io=0x5ff770 alloc_size=(nil) attr=00000000 sharing=00000001 disp=1 options=00000060 ea=(nil).0x00000000 002e:trace:file:nt_to_unix_file_name_internal L"\\??\\C:\\windows\\system32\\ntdll.dll" -> "/home/focht/.wine/dosdevices/c:/windows/system32/ntdll.dll" 002e: create_file( access=80100000, sharing=00000001, create=1, options=00000060, attrs=00000000, objattr={rootdir=0000,attributes=00000040,sd={},name=L""}, filename="/home/focht/.wine/dosdevices/c:/windows/system32/ntdll.dll" ) 002e: create_file() = 0 { handle=0024 } 002e:trace:file:CreateFileW returning 0x24 002e: create_mapping( access=000f0005, flags=08000000, file_access=00000001, size=00000000, file_handle=0024, objattr={rootdir=0000,attributes=00000080,sd={},name=L""} ) 002e: create_mapping() = 0 { handle=0028 } 002e: get_mapping_info( handle=0028, access=00000004 ) 002e: get_mapping_info() = 0 { size=0000edac, flags=00800000, shared_file=0000, image={} } 002e: get_handle_fd( handle=0028 ) 002e: *fd* 0028 -> 31 002e: get_handle_fd() = 0 { type=1, cacheable=1, access=000f0005, options=00000020 } 002e: map_view( mapping=0028, access=00000004, base=00600000, size=0000f000, start=00000000 ) 002e: map_view() = 0 002e: unmap_view( base=00600000 ) 002e: unmap_view() = 0 002e: close_handle( handle=0028 ) 002e: close_handle() = 0 002e: close_handle( handle=0024 ) 002e: close_handle() = 0 002e:trace:ntdll:RtlSystemTimeToLocalTime (0x5ffb30, 0x5ffb28) 002e:trace:file:CreateFileW L"\\\\.\\mailslot\\ErrLog-Pec72FB" GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 002e:trace:file:RtlDosPathNameToNtPathName_U_WithStatus (L"\\\\.\\mailslot\\ErrLog-Pec72FB",0x5ff1f0,(nil),(nil)) 002e:trace:file:RtlGetFullPathName_U (L"\\\\.\\mailslot\\ErrLog-Pec72FB" 520 0x5fede0 (nil)) 002e:trace:ntdll:FILE_CreateFile handle=0x5ff1d8 access=40100000 name=L"\\??\\mailslot\\ErrLog-Pec72FB" objattr=00000040 root=(nil) sec=(nil) io=0x5ff1e0 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000060 ea=(nil).0x00000000 002e: open_file_object( access=40100000, attributes=00000040, rootdir=0000, sharing=00000003, options=00000060, filename=L"\\??\\mailslot\\ErrLog-Pec72FB" ) 002e: open_file_object() = OBJECT_NAME_NOT_FOUND { handle=0000 } 002e:warn:file:CreateFileW Unable to create file L"\\\\.\\mailslot\\ErrLog-Pec72FB" (status c0000034) 002e:trace:file:CreateFileW returning 0xffffffffffffffff 002e:trace:file:CreateFileW L"\\\\.\\mailslot\\ErrLog-Pec72FB" GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 002e:trace:file:RtlDosPathNameToNtPathName_U_WithStatus (L"\\\\.\\mailslot\\ErrLog-Pec72FB",0x5ff1f0,(nil),(nil)) 002e:trace:file:RtlGetFullPathName_U (L"\\\\.\\mailslot\\ErrLog-Pec72FB" 520 0x5fede0 (nil)) 002e:trace:ntdll:FILE_CreateFile handle=0x5ff1d8 access=40100000 name=L"\\??\\mailslot\\ErrLog-Pec72FB" objattr=00000040 root=(nil) sec=(nil) io=0x5ff1e0 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000060 ea=(nil).0x00000000 002e: open_file_object( access=40100000, attributes=00000040, rootdir=0000, sharing=00000003, options=00000060, filename=L"\\??\\mailslot\\ErrLog-Pec72FB" ) 002e: open_file_object() = OBJECT_NAME_NOT_FOUND { handle=0000 } 002e:warn:file:CreateFileW Unable to create file L"\\\\.\\mailslot\\ErrLog-Pec72FB" (status c0000034) 002e:trace:file:CreateFileW returning 0xffffffffffffffff 002e: terminate_process( handle=0000, exit_code=0 ) 002e: terminate_process() = 0 { self=1 } 002e:trace:module:LdrShutdownProcess () --- snip --- Tidbit: The mailslot thing seems to belong to some internal error handling. It is interesting because such unique patterns help sometimes to identify the protection scheme/used 3rd party library code. Unfortunately a search of '\\\.\\mailslot\\ErrLog-Pec*' reveals not that much. https://www.google.de/search?&q="\.\mailslot\ErrLog" Some samples from malware analysis sites. --- To come to this point one has to defeat some simple anti-debugging checks. Use of hardware breakpoints is mandatory due to code being dynamically unpacked. === #1 === --- snip --- 002e:Call KERNEL32.IsDebuggerPresent() ret=143fca16e 002e:Ret KERNEL32.IsDebuggerPresent() retval=00000000 ret=143fca16e --- snip --- --- snip --- ... 0000000143FCA169 | 48 8B F8 | mov rdi, rax 0000000143FCA16C | FF D3 | call rbx 0000000143FCA16E | 48 8B 74 24 40 | mov rsi, qword ptr ss:[rsp+40] 0000000143FCA173 | 85 C0 | test eax, eax 0000000143FCA175 | 48 8B 5C 24 38 | mov rbx, qword ptr ss:[rsp+38] ; set ZF=1 0000000143FCA17A | 74 20 | je streetfighterv.143FCA19C ... --- snip --- === #2 === --- snip --- 002e:Call KERNEL32.CheckRemoteDebuggerPresent(ffffffffffffffff,005ffd00) ret=143fca1b4 002e:Call ntdll.NtQueryInformationProcess(ffffffffffffffff,00000007,005ffc38,00000008,00000000) ret=7b48d9e8 002e:trace:ntdll:NtQueryInformationProcess (0xffffffffffffffff,0x00000007,0x5ffc38,0x00000008,(nil)) 002e: get_process_info( handle=ffffffff ) 002e: get_process_info() = 0 { pid=002d, ppid=0000, affinity=000000ff, peb=7fffffeaf000, start_time=1d3e151f13af5a8 (-0.0174060), end_time=0, exit_code=259, priority=2, cpu=x86_64, debugger_present=0, debug_children=1 } 002e:Ret ntdll.NtQueryInformationProcess() retval=00000000 ret=7b48d9e8 002e:Ret KERNEL32.CheckRemoteDebuggerPresent() retval=00000001 ret=143fca1b4 --- snip --- --- snip --- 0000000143FCA1A1 | 48 8D 54 24 30 | lea rdx, qword ptr ss:[rsp+30] 0000000143FCA1A6 | 48 83 C9 FF | or rcx, FFFFFFFFFFFFFFFF 0000000143FCA1AA | C7 44 24 30 01 00 00.| mov dword ptr ss:[rsp+30], 1 0000000143FCA1B2 | FF D7 | call rdi 0000000143FCA1B4 | 83 7C 24 30 00 | cmp dword ptr ss:[rsp+30], 0 ; set ZF=1 0000000143FCA1B9 | 75 04 | jne streetfighterv.143FCA1BF --- snip --- === #3 === Inlined variant of PEB debugger check --- snip --- ; TEB 0000000143FCFA53 | 65 4C 8B 1C 25 30 00.| mov r11, qword ptr gs:[30] 0000000143FCFA5C | 33 DB | xor ebx, ebx ; PEB 0000000143FCFA5E | 49 8B 4B 60 | mov rcx, qword ptr ds:[r11 + 60] ; being debugged? 0000000143FCFA62 | 38 59 02 | cmp byte ptr ds:[rcx + 2], bl ; zero out BL 0000000143FCFA65 | 0F 95 C3 | setne bl 0000000143FCFA68 | EB 01 | jmp streetfighterv.143FCFA6B 0000000143FCFA6A | EB E8 | jmp streetfighterv.143FCFA54 --- snip --- === #4 === --- snip --- $ WINEDEBUG=+seh,+server,+ntdll wine ./StreetFighterV.exe >>log.txt 2>&1 ... 002e:trace:ntdll:NtQueryInformationProcess (0xffffffffffffffff,0x00000007,0x5ffcb0,0x00000008,0x5ffcb0) 002e: get_process_info( handle=ffffffff ) 002e: get_process_info() = 0 { pid=002d, ppid=0000, affinity=000000ff, peb=7fffffeaf000, start_time=1d3e17d69097156 (-0.0309210), end_time=0, exit_code=259, priority=2, cpu=x86_64, debugger_present=0, debug_children=1 } ... --- snip --- --- snip --- ; preset app flag 0000000143FCE79C | C7 44 24 30 01 | mov dword ptr ss:[rsp+30], 1 0000000143FCE7A4 | E8 9F 13 00 00 | call streetfighterv.143FCFB48 ... 0000000143FCFB71 | 48 8B CB | mov rcx, rbx 0000000143FCFB74 | 4C 89 5C 24 20 | mov qword ptr ss:[rsp+20], r11 ; NtQueryInformationProcess, ProcessDebugPort 0000000143FCFB79 | E8 0A FF FF FF | call streetfighterv.143FCFA88 0000000143FCFB7E | 85 C0 | test eax, eax 0000000143FCFB80 | 74 0D | je streetfighterv.143FCFB8F 0000000143FCFB82 | 33 C0 | xor eax, eax 0000000143FCFB84 | 48 8B 5C 24 40 | mov rbx, qword ptr ss:[rsp+40] 0000000143FCFB89 | 48 83 C4 30 | add rsp, 30 0000000143FCFB8D | 5F | pop rdi 0000000143FCFB8E | C3 | ret ; reset app flag NTSTATUS == STATUS_SUCCESS 0000000143FCFB8F | C7 07 00 00 00. | mov dword ptr ds:[rdi], 0 0000000143FCFB95 | EB 01 | jmp streetfighterv.143FCFB98 0000000143FCFB97 | EB E8 | jmp streetfighterv.143FCFB81 0000000143FCFB99 | 03 00 | add eax, dword ptr ds:[rax] 0000000143FCFB9B | 00 00 | add byte ptr ds:[rax], al 0000000143FCFB9D | 66 48 B9 48 83. | mov rcx, 245C8B4808C48348 ... 0000000143FCFBA0 | 48 83 C4 08 | add rsp, 8 0000000143FCFBA4 | 48 8B 5C 24 40 | mov rbx, qword ptr ss:[rsp+40] 0000000143FCFBA9 | B8 01 00 00 00 | mov eax, 1 0000000143FCFBAE | 48 83 C4 30 | add rsp, 30 0000000143FCFBB2 | 5F | pop rdi 0000000143FCFBB3 | C3 | ret ... ; app flag == 0? 0000000143FCE7A9 | 83 7C 24 30 00 | cmp dword ptr ss:[rsp+30], 0 0000000143FCE7AE | 75 33 | jne streetfighterv.143FCE7E3 0000000143FCE7B0 | 85 C0 | test eax, eax 0000000143FCE7B2 | 74 2F | je streetfighterv.143FCE7E3 --- snip --- 'ProcessDebugPort' -> anti-debug check, the call is made via a copy of 'ntdll.NtQueryInformationProcess' entry hence the 64-bit syscall thunks are needed -> bug 45349 The check here seems kinda pointless, the code doesn't look at 'ProcessDebugPort' return value at all. It only validates return status -> app bug? ===================== And the final frontier ... Caller code that maps the 'ntdll.dll' placeholder into memory to validate it with in-memory 'ntdll.dll' PE image. --- snip --- ... 0000000143FED295 | mov r13, qword ptr ds:[r14] 0000000143FED298 | lea rcx, qword ptr ss:[rsp + 60] 0000000143FED29D | mov edx, 104 0000000143FED2A2 | xor esi, esi 0000000143FED2A4 | call <streetfighterv.GetSystemWindowsDirectoryA> ... 0000000143FED31E | mov qword ptr ss:[rsp + 30], rsi 0000000143FED323 | lea rcx, qword ptr ss:[rsp + 60] 0000000143FED328 | lea r8d, qword ptr ds:[r9 + 1] 0000000143FED32C | mov edx, 80000000 0000000143FED331 | mov dword ptr ss:[rsp + 28], esi 0000000143FED335 | mov dword ptr ss:[rsp + 20], 3 0000000143FED33D | call qword ptr ds:[<&CreateFileA>] 0000000143FED343 | mov edi, esi 0000000143FED345 | mov rbp, rsi 0000000143FED348 | cmp rax, FFFFFFFFFFFFFFFF 0000000143FED34C | mov r12, rax 0000000143FED34F | setne dil 0000000143FED353 | test edi, edi 0000000143FED355 | je streetfighterv.143FED38B 0000000143FED357 | xor edx, edx 0000000143FED359 | mov ecx, E3 0000000143FED35E | call qword ptr ds:[143FEEE50] 0000000143FED364 | xor r9d, r9d 0000000143FED367 | xor edx, edx 0000000143FED369 | lea r8d, qword ptr ds:[r9 + 2] 0000000143FED36D | mov rcx, r12 0000000143FED370 | mov qword ptr ss:[rsp + 28], rsi 0000000143FED375 | mov dword ptr ss:[rsp + 20], esi 0000000143FED379 | call qword ptr ds:[<&CreateFileMappingA>] 0000000143FED37F | mov edi, esi 0000000143FED381 | test rax, rax 0000000143FED384 | mov rbp, rax 0000000143FED387 | setne dil 0000000143FED38B | test edi, edi 0000000143FED38D | mov rbx, rsi 0000000143FED390 | je streetfighterv.143FED406 0000000143FED392 | xor edx, edx 0000000143FED394 | mov ecx, F3 0000000143FED399 | call qword ptr ds:[143FEEE50] 0000000143FED39F | xor r9d, r9d 0000000143FED3A2 | xor r8d, r8d 0000000143FED3A5 | lea edx, qword ptr ds:[r9 + 4] 0000000143FED3A9 | mov rcx, rbp 0000000143FED3AC | mov qword ptr ss:[rsp + 20], rsi ; map placeholder image 0000000143FED3B1 | call qword ptr ds:[<&MapViewOfFile>] 0000000143FED3B7 | mov edi, esi 0000000143FED3B9 | test rax, rax 0000000143FED3BC | mov rbx, rax 0000000143FED3BF | setne dil 0000000143FED3C3 | test edi, edi 0000000143FED3C5 | je streetfighterv.143FED406 0000000143FED3C7 | xor edx, edx 0000000143FED3C9 | mov ecx, 103 0000000143FED3CE | call qword ptr ds:[143FEEE50] 0000000143FED3D4 | mov rdx, rbx 0000000143FED3D7 | mov rcx, r15 ; check disk PE header vs. in-memory PE header (phase 1 validate) 0000000143FED3DA | call streetfighterv.143FECB30 0000000143FED3DF | test eax, eax 0000000143FED3E1 | mov edi, eax ; mismatch -> jump 0000000143FED3E3 | je streetfighterv.143FED406 0000000143FED3E5 | xor edx, edx 0000000143FED3E7 | mov ecx, 113 0000000143FED3EC | call qword ptr ds:[143FEEE50] 0000000143FED3F2 | mov rcx, rbx 0000000143FED3F5 | call streetfighterv.143FECA30 0000000143FED3FA | xor edi, edi 0000000143FED3FC | test rax, rax 0000000143FED3FF | mov rsi, rax 0000000143FED402 | setne dil 0000000143FED406 | test rbx, rbx 0000000143FED409 | je streetfighterv.143FED414 0000000143FED40B | mov rcx, rbx 0000000143FED40E | call qword ptr ds:[<&UnmapViewOfFile>] 0000000143FED414 | test rbp, rbp 0000000143FED417 | je streetfighterv.143FED422 0000000143FED419 | mov rcx, rbp 0000000143FED41C | call qword ptr ds:[<&CloseHandle>] 0000000143FED422 | cmp r12, FFFFFFFFFFFFFFFF 0000000143FED426 | je streetfighterv.143FED431 0000000143FED428 | mov rcx, r12 0000000143FED42B | call qword ptr ds:[<&CloseHandle>] 0000000143FED431 | test edi, edi 0000000143FED433 | je streetfighterv.143FED4CA ... --- snip --- in-memory 'ntdll.dll' (sections = 2) --- snip --- $ ==> 50 45 00 00 64 86 02 00 00 00 00 00 00 00 00 00 PE..d........... $+10 00 00 00 00 F0 00 22 20 0B 02 07 0A 00 60 10 00 ....ð." .....`.. $+20 00 00 02 00 00 00 00 00 F0 B8 0B 00 00 10 00 00 ........ð¸...... $+30 00 00 C4 7B 00 00 00 00 00 10 00 00 00 10 00 00 ..Ä{............ $+40 01 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 ................ $+50 00 70 12 00 00 10 00 00 00 00 00 00 00 00 00 01 .p.............. $+60 00 00 10 00 00 00 00 00 00 10 00 00 00 00 00 00 ................ $+70 00 00 10 00 00 00 00 00 00 10 00 00 00 00 00 00 ................ $+80 00 00 00 00 10 00 00 00 40 7D 10 00 48 A1 00 00 ........@}..H¡.. $+90 00 00 00 00 00 00 00 00 B8 1E 11 00 AC 03 00 00 ........¸...¬... $+A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+100 00 00 00 00 00 00 00 00 2E 74 65 78 74 00 00 00 .........text... --- snip --- placedholder/fake-dll mapped disk view (sections = 4): --- snip --- $ ==> 50 45 00 00 64 86 04 00 00 00 00 00 00 00 00 00 PE..d........... $+10 00 00 00 00 F0 00 22 20 0B 02 07 0A 97 CE 00 00 ....ð." .....Î.. $+20 00 00 00 00 00 00 00 00 70 50 00 00 00 10 00 00 ........pP...... $+30 00 00 00 10 00 00 00 00 00 10 00 00 00 02 00 00 ................ $+40 01 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 ................ $+50 00 20 01 00 00 04 00 00 00 00 00 00 00 00 00 01 . .............. $+60 00 00 10 00 00 00 00 00 00 10 00 00 00 00 00 00 ................ $+70 00 00 10 00 00 00 00 00 00 10 00 00 00 00 00 00 ................ $+80 00 00 00 00 10 00 00 00 80 50 00 00 17 8E 00 00 .........P...... $+90 00 00 00 00 00 00 00 00 00 10 01 00 AC 03 00 00 ............¬... $+A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+B0 00 00 01 00 08 00 00 00 00 00 00 00 00 00 00 00 ................ $+C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ $+100 00 00 00 00 00 00 00 00 2E 74 65 78 74 00 00 00 .........text... --- snip --- Validation (phase 1): --- snip --- ... ; e_magic 0000000143FE9D45 | 66 81 3B 4D 5A | cmp word ptr ds:[rbx], 5A4D 0000000143FE9D4A | 75 F1 | jne streetfighterv.143FE9D3D 0000000143FE9D4C | 48 89 7C 24 30 | mov qword ptr ss:[rsp+30], rdi ; DWORD e_lfanew 0000000143FE9D51 | 48 63 7B 3C | movsxd rdi, dword ptr ds:[rbx+3C] 0000000143FE9D55 | 48 03 FB | add rdi, rbx ; PE signature, 'PE' from in-memory image 0000000143FE9D58 | 81 3F 50 45 00 00 | cmp dword ptr ds:[rdi], 4550 0000000143FE9D5E | 74 0D | je streetfighterv.143FE9D6D 0000000143FE9D60 | 33 C0 | xor eax, eax 0000000143FE9D62 | 48 8B 7C 24 30 | mov rdi, qword ptr ss:[rsp+30] 0000000143FE9D67 | 48 83 C4 20 | add rsp, 20 0000000143FE9D6B | 5B | pop rbx 0000000143FE9D6C | C3 | ret 0000000143FE9D6D | EB 01 | jmp streetfighterv.143FE9D70 0000000143FE9D6F | EB E8 | jmp streetfighterv.143FE9D59 0000000143FE9D71 | 03 00 | add eax, dword ptr ds:[rax] 0000000143FE9D73 | 00 00 | add byte ptr ds:[rax], al 0000000143FE9D75 | 66 48 B9 48 83 C4.| mov rcx, 48C78B4808C48348 0000000143FE9D80 | 8B 7C 24 30 | mov edi, dword ptr ss:[rsp+30] 0000000143FE9D84 | 48 83 C4 20 | add rsp, 20 0000000143FE9D88 | 5B | pop rbx 0000000143FE9D89 | C3 | ret ... 0000000143FECB80 | 48 85 C0 | test rax, rax 0000000143FECB83 | 48 8B F8 | mov rdi, rax 0000000143FECB86 | 74 16 | je streetfighterv.143FECB9E ; DWORD AddressOfEntryPoint disk image (RVA: 0x5070) 0000000143FECB88 | 8B 40 28 | mov eax, dword ptr ds:[rax+28] ; dword ptr [rbx+28]=[ntdll.000000007BC40068]=BB8F0 0000000143FECB8B | 39 43 28 | cmp dword ptr ds:[rbx+28], eax 0000000143FECB8E | 75 0E | jne streetfighterv.143FECB9E ; DWORD size of Import Directory (array of IIDs) in-memory view: 0x10 0000000143FECB90 | 8B 83 84 00 00 00 | mov eax, dword ptr ds:[rbx+84] ; dword ptr [rdi+84]=[00000000006100E4]=10 0000000143FECB96 | 3B 87 84 00 00 00 | cmp eax, dword ptr ds:[rdi+84] 0000000143FECB9C | 74 12 | je streetfighterv.143FECBB0 0000000143FECB9E | 33 C0 | xor eax, eax 0000000143FECBA0 | 48 8B 6C 24 30 | mov rbp, qword ptr ss:[rsp+30] 0000000143FECBA5 | 48 8B 5C 24 40 | mov rbx, qword ptr ss:[rsp+40] 0000000143FECBAA | 48 83 C4 20 | add rsp, 20 0000000143FECBAE | 5F | pop rdi 0000000143FECBAF | C3 | ret ... 0000000143FECBB0 | 48 89 74 24 38 | mov qword ptr ss:[rsp+38], rsi ; WORD NumberOfSections ; word ptr [rbx+6]=[ntdll.000000007BC40046]=2 0000000143FECBB5 | 0F B7 73 06 | movzx esi, word ptr ds:[rbx+6] ; word ptr [rdi+6]=[0000000000610066]=4 0000000143FECBB9 | 66 3B 77 06 | cmp si, word ptr ds:[rdi+6] 0000000143FECBBD | 75 3E | jne streetfighterv.143FECBFD 0000000143FECBBF | 4C 8B C0 | mov r8, rax ; DWORD Resource Table / RVA of Resource Directory ; edx=00000000006100E8 0000000143FECBC2 | 48 8D 97 88 00 00.| lea rdx, qword ptr ds:[rdi+88] ; rcx=ntdll.000000007BC400C8 0000000143FECBC9 | 48 8D 8B 88 00 00.| lea rcx, qword ptr ds:[rbx+88] 0000000143FECBD0 | 49 C1 E0 03 | shl r8, 3 0000000143FECBD4 | E8 F7 1E 00 00 | call streetfighterv.143FEEAD0 0000000143FECBD9 | 85 C0 | test eax, eax 0000000143FECBDB | 75 20 | jne streetfighterv.143FECBFD 0000000143FECBDD | 0F B7 C6 | movzx eax, si 0000000143FECBE0 | 48 8B CD | mov rcx, rbp 0000000143FECBE3 | 4C 8D 04 80 | lea r8, qword ptr ds:[rax+rax*4] 0000000143FECBE7 | 0F B7 47 14 | movzx eax, word ptr ds:[rdi+14] 0000000143FECBEB | 48 8D 54 38 18 | lea rdx, qword ptr ds:[rax+rdi+1 0000000143FECBF0 | 49 C1 E0 03 | shl r8, 3 0000000143FECBF4 | E8 D7 1E 00 00 | call streetfighterv.143FEEAD0 0000000143FECBF9 | 85 C0 | test eax, eax 0000000143FECBFB | 74 04 | je streetfighterv.143FECC01 0000000143FECBFD | 33 C0 | xor eax, eax 0000000143FECBFF | EB 14 | jmp streetfighterv.143FECC15 0000000143FECC01 | EB 02 | jmp streetfighterv.143FECC05 0000000143FECC03 | 48 EB E8 | jmp streetfighterv.143FECBEE 0000000143FECC06 | 02 00 | add al, byte ptr ds:[rax] 0000000143FECC08 | 00 00 | add byte ptr ds:[rax], al 0000000143FECC0A | 48 B9 48 83 C4 08.| mov rcx, 1B808C48348 0000000143FECC14 | 00 48 8B | add byte ptr ds:[rax-75], cl 0000000143FECC17 | 74 24 | je streetfighterv.143FECC3D 0000000143FECC19 | 38 48 8B | cmp byte ptr ds:[rax-75], cl 0000000143FECC1C | 6C | insb 0000000143FECC1D | 24 30 | and al, 30 0000000143FECC1F | 48 8B 5C 24 40 | mov rbx, qword ptr ss:[rsp+40] 0000000143FECC24 | 48 83 C4 20 | add rsp, 20 0000000143FECC28 | 5F | pop rdi 0000000143FECC29 | C3 | ret ... --- snip --- I've left out the actual data directory traversal (would be too much). This just shows it extensively validates to in-memory PE image against the disk image. 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.

2 6

[Bug 36873] New: Chronology (.NET 4.0 game) based on 'OpenTK': mouse input non-functional, mouse cursor invisible
by wine-bugs＠winehq.org Oct. 24, 2020

Oct. 24, 2020

https://bugs.winehq.org/show_bug.cgi?id=36873 Bug ID: 36873 Summary: Chronology (.NET 4.0 game) based on 'OpenTK': mouse input non-functional, mouse cursor invisible Product: Wine Version: 1.7.21 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, the GOG.com version installs .NET Framework 4.0 client profile on its own in clean 32-bit WINEPREFIX (without Mono). If the mouse is moved (either in fullscreen or virtual desktop mode), the console is spammed with: --- snip --- fixme:win:GetMouseMovePointsEx (16 0x33ea10 0x33e5cc 64 1) stub fixme:win:GetMouseMovePointsEx (16 0x33ea10 0x33e5cc 64 1) stub fixme:win:GetMouseMovePointsEx (16 0x33ea10 0x33e5cc 64 1) stub --- snip --- Source: http://source.winehq.org/git/wine.git/blob/bdc9b147b948b3476815c52f7fc53f4c… --- snip --- 1427 int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) { 1428 1429 if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) { 1430 SetLastError(ERROR_INVALID_PARAMETER); 1431 return -1; 1432 } 1433 1434 if(!ptin || (!ptout && count)) { 1435 SetLastError(ERROR_NOACCESS); 1436 return -1; 1437 } 1438 1439 FIXME("(%d %p %p %d %d) stub\n", size, ptin, ptout, count, res); 1440 1441 SetLastError(ERROR_POINT_NOT_FOUND); 1442 return -1; 1443 } --- snip --- MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/ms646259%28v=vs.85%… That noisy stub (although annoying) doesn't seem to be the problem here. See here for discussion and how it's implemented in 'OpenTK': https://github.com/opentk/opentk/issues/76 https://github.com/opentk/opentk/blob/develop/Source/OpenTK/Platform/Window… --- snip --- void HandleMouseMove(IntPtr handle, WindowMessage message, IntPtr wParam, IntPtr lParam) { unsafe { Point point = new Point( (short)((uint)lParam.ToInt32() & 0x0000FFFF), (short)(((uint)lParam.ToInt32() & 0xFFFF0000) >> 16)); // GetMouseMovePointsEx works with screen coordinates Point screenPoint = point; Functions.ClientToScreen(handle, ref screenPoint); int timestamp = Functions.GetMessageTime(); // & 0xFFFF to handle multiple monitors http://support.microsoft.com/kb/269743 MouseMovePoint movePoint = new MouseMovePoint() { X = screenPoint.X & 0xFFFF, Y = screenPoint.Y & 0xFFFF, Time = timestamp, }; // Max points GetMouseMovePointsEx can return is 64. const int numPoints = 64; MouseMovePoint* movePoints = stackalloc MouseMovePoint[numPoints]; // GetMouseMovePointsEx fills in movePoints so that the most // recent events are at low indices in the array. int points = Functions.GetMouseMovePointsEx( (uint)MouseMovePoint.SizeInBytes, &movePoint, movePoints, numPoints, Constants.GMMP_USE_DISPLAY_POINTS); int lastError = Marshal.GetLastWin32Error(); // No points returned or search point not found if (points == 0 || (points == -1 && lastError == Constants.ERROR_POINT_NOT_FOUND)) { // Just use the mouse move position OnMouseMove(point.X, point.Y); } else if (points == -1) { throw new System.ComponentModel.Win32Exception(lastError); } else { ... --- snip --- That information might be still useful for 'GetMouseMovePointsEx' implementation though. $ wine --version wine-1.7.21-75-g0a4c786 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.

2 27

[Bug 49135] New: 3DMark06 cannot be installed: "The CPU of this system does not support SSE instructions"
by WineHQ Bugzilla Oct. 24, 2020

Oct. 24, 2020

https://bugs.winehq.org/show_bug.cgi?id=49135 Bug ID: 49135 Summary: 3DMark06 cannot be installed: "The CPU of this system does not support SSE instructions" Product: Wine Version: 5.8 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: aros(a)gmx.com Distribution: --- Created attachment 67138 --> https://bugs.winehq.org/attachment.cgi?id=67138 Installer It used to be installable. $ wine 3DMark06_v121_installer.exe 0070:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\wineusb": c0000142 003c:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 1114 0024:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet 0024:fixme:apphelp:ApphelpCheckInstallShieldPackage stub: 0031F2AC L"C:\\users\\birdie\\Temp\\{9ECBE0A5-94B8-4225-8A90-777902F90B40}\\Disk1\\data1.hdr" -- 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 14