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

[Bug 45437] New: Readme' s installation instructions link leads to winehq page with no installation instructions
by wine-bugs＠winehq.org Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=45437 Bug ID: 45437 Summary: Readme's installation instructions link leads to winehq page with no installation instructions Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: root(a)swooshalicio.us CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- The readme in the wine-staging repository links to https://wine-staging.com/installation.html which redirects to https://wiki.winehq.org/Wine-Staging which contains no information for installing wine-staging. -- 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 48188] New: wine fails to load, "kernelbase.dll" failed to initialize, aborting
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48188 Bug ID: 48188 Summary: wine fails to load, "kernelbase.dll" failed to initialize, aborting Product: Wine Version: 4.20 Hardware: x86 OS: Linux Status: NEW Keywords: download, regression Severity: critical Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com CC: julliard(a)winehq.org Distribution: --- 000b:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 000b:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\wineboot.exe" failed, status c0000005 0009:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 0009:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\wineboot.exe" failed, status c0000005 d05c9f12fb9409e2bc65bb59fa596c9872915d40 is the first bad commit commit d05c9f12fb9409e2bc65bb59fa596c9872915d40 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Nov 27 09:54:51 2019 +0100 kernelbase: Initialize codepage data using ntdll functions. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> :040000 040000 46104b3961726d8c6d83abb04a7619008d88aad1 bedb6cb4be88dc3711d75909d60ca4d89dfb6702 M dlls mingw is enabled: austin(a)laptop ~/wine-git ((no branch, bisect started on master)) $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-w64-mingw32/9.2.0/lto-wrapper Target: i686-w64-mingw32 Configured with: /var/tmp/portage/cross-i686-w64-mingw32/gcc-9.2.0-r2/work/gcc-9.2.0/configure --host=x86_64-pc-linux-gnu --target=i686-w64-mingw32 --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/i686-w64-mingw32/gcc-bin/9.2.0 --includedir=/usr/lib/gcc/i686-w64-mingw32/9.2.0/include --datadir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0 --mandir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0/man --infodir=/usr/share/gcc-data/i686-w64-mingw32/9.2.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-w64-mingw32/9.2.0/include/g++-v9 --with-python-dir=/share/gcc-data/i686-w64-mingw32/9.2.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.2.0-r2 p3' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-poison-system-directories --with-sysroot=/usr/i686-w64-mingw32 --disable-bootstrap --disable-multilib --disable-altivec --disable-fixed-point --with-arch=i686 --enable-targets=all --disable-libgomp --disable-libmudflap --disable-systemtap --disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer --disable-default-pie --enable-default-ssp Thread model: win32 gcc version 9.2.0 (Gentoo 9.2.0-r2 p3) -- 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 4

[Bug 46047] New: Multiple applications want Windows 8+ futex-like operations kernel32.dll.WaitOnAddress , kernel32.dll.WakeByAddress{All,Single} (VLC)
by wine-bugs＠winehq.org Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=46047 Bug ID: 46047 Summary: Multiple applications want Windows 8+ futex-like operations kernel32.dll.WaitOnAddress, kernel32.dll.WakeByAddress{All,Single} (VLC) Product: Wine Version: 3.18 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, to track: * https://www.winehq.org/pipermail/wine-devel/2018-October/134085.html * https://www.winehq.org/pipermail/wine-devel/2018-October/134086.html There is a series of articles on the background/inner workings of this Windows 8+ futex-like operations by Raymond Chen on Microsoft developer blog "The Old New Thing": (1) https://blogs.msdn.microsoft.com/oldnewthing/20160823-00/?p=94145 ("WaitOnAddress lets you create a synchronization object out of any data variable, even a byte") (2) https://blogs.msdn.microsoft.com/oldnewthing/20160824-00/?p=94155 ("Implementing a synchronization barrier in terms of WaitOnAddress") (3) https://blogs.msdn.microsoft.com/oldnewthing/20160825-00/?p=94165 ("Implementing a critical section in terms of WaitOnAddress") (4) https://blogs.msdn.microsoft.com/oldnewthing/20160826-00/?p=94185 ("Spurious wakes, race conditions, and bogus FIFO claims: A peek behind the curtain of WaitOnAddress") Alternative overview to the blog using Github-based WIKI: https://github.com/mity/mctrl/wiki/Old-New-Win32API (click the sections to get to blog entries) WaitOnAddress() * WaitOnAddress lets you create a synchronization object out of any data variable, even a byte * Implementing a synchronization barrier in terms of WaitOnAddress * Implementing a critical section in terms of WaitOnAddress * Extending our critical section based on WaitOnAddress to support timeouts * Comparing WaitOnAddress with futexes (futexi? futexen?) * Creating a semaphore from WaitOnAddress * Creating a semaphore with a maximum count from WaitOnAddress * Creating a manual-reset event from WaitOnAddress * Creating an automatic-reset event from WaitOnAddress Related: bug 45524 ("Add a futex-based implementation of condition variables") I found multiple applications which make use of this Windows 8+ API. Example: VLC https://github.com/videolan/vlc/blob/master/src/win32/thread.c Most of them have fallback implementations if the API is not available so it's not critical to the functionality. But it's still good to have real world tests :-) 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 10

[Bug 47766] New: PathAllocCanonicalize treats path segments start with dots wrong.
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=47766 Bug ID: 47766 Summary: PathAllocCanonicalize treats path segments start with dots wrong. Product: Wine Version: 4.16 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: zzhang(a)codeweavers.com Distribution: --- This bug was reported on wine-devel mail list by Sebastian M. Ernst <ernst(a)pleiszenburg.de> user(a)comp:/path/other> WINEDEBUG=-all PYTHONHOME="z:\\path\\.to\\target" wine /path/.to/target/python.exe -c "import sys; print(sys.executable)" Z:\pathto\target\python.exe PYTHONHOME="z:\\path\\..to\\target" wine /path/..to/target/python.exe -c "import sys; print(sys.executable)" Z:\to\target\python.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 9

[Bug 48542] New: Mono (and probably .NET) needs CreateThreadpoolIo
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48542 Bug ID: 48542 Summary: Mono (and probably .NET) needs CreateThreadpoolIo Product: Wine Version: 5.0 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: madewokherd(a)gmail.com Distribution: --- Found testing LiveSplit 1.7.7 on Wine Mono from the master branch. Mono's implementation of System.Threading.ThreadPoolBoundHandle depends on CreateThreadpoolIo. Wine's stub of this function returns 0 and doesn't set last error, resulting in the confusing message "System.IO.IOException: Success". This can be more easily reproduced by running 'make test' in Wine Mono and running tests/run-tests.exe MonoTests.System.IO.Pipes.PipeSecurityTest:NamedPipePermissionsActuallyWorkAsync -- 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 8

[Bug 48471] New: Mismatching behavior of GetEnvironmentVariableW for empty / long values
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48471 Bug ID: 48471 Summary: Mismatching behavior of GetEnvironmentVariableW for empty / long values Product: Wine Version: 5.0-rc4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: wine(a)thecybershadow.net Distribution: --- Attempting to build the Windows version of DMD, the reference compiler for the D programming language, fails under Wine. This seems to be caused by the following chain of events: 1. The makefile invokes a build program with a "VERBOSE=" on the command-line: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… (Here "$(VERBOSE)" is not set and expands to the empty string.) 2. The build program registers the command-line arguments into the process environment: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… This sets the environment variable VERBOSE to the empty string. 3. Later, it attempts to check if the "VERBOSE" variable is in the environment: https://github.com/dlang/dmd/blob/49dfbe54f4a0f62a0694aec9fb4184739903a0c2/… 4. This calls the following Windows code in the standard library to read the environment: https://github.com/dlang/phobos/blob/e373b4e77448bc11c6e4ea6c85bcdb8f7ab86f… 5. For empty variables, the code behaves differently in Windows and Wine - Wine's implementation returns 0, while Windows returns 1. As a result, the standard library code throws an exception under Wine. Writing a test program reveals further differences. The program: #include <stdio.h> #include <windows.h> void main() { WCHAR buf[4]; DWORD size; int len, i; for (len = 0; len <= 2; len++) { for (i = 0; i < len; i++) buf[i] = 'a'; buf[len] = 0; SetEnvironmentVariableW(L"TESTVAR", buf); for (i = 0; i <= len + 1; i++) { DWORD err; SetLastError(1); buf[0] = 1; size = GetEnvironmentVariableW(L"TESTVAR", buf, i); err = GetLastError(); printf("%d->%d: size=%d error=%d buf[0]=%d\n", len, i, size, err, buf[0]); } printf("\n"); } } Output on Windows [Version 10.0.17134.648]: 0->0: size=1 error=1 buf[0]=1 0->1: size=0 error=1 buf[0]=0 1->0: size=2 error=1 buf[0]=1 1->1: size=2 error=1 buf[0]=0 1->2: size=1 error=1 buf[0]=97 2->0: size=3 error=1 buf[0]=1 2->1: size=3 error=1 buf[0]=0 2->2: size=3 error=1 buf[0]=0 2->3: size=2 error=1 buf[0]=97 Output on Wine: 0->0: size=0 error=1 buf[0]=1 0->1: size=0 error=1 buf[0]=0 1->0: size=2 error=122 buf[0]=1 1->1: size=2 error=122 buf[0]=1 1->2: size=1 error=1 buf[0]=97 2->0: size=3 error=122 buf[0]=1 2->1: size=3 error=122 buf[0]=1 2->2: size=3 error=122 buf[0]=1 2->3: size=2 error=1 buf[0]=97 We can observe these differences: 1. Wine returns 0 and not 1 when the variable is empty and the function is given a zero-length buffer. 2. Wine sets the last error to ERROR_INSUFFICIENT_BUFFER, while Windows doesn't. 3. Windows zeroes the buffer if the size is non-zero but still insufficient to hold the value. (This is not a bug as the behavior is specified in the documentation to be undefined.) -- 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 47061] New: Multiple E-Banking applications by KOBIL Systems GmbH crash on startup or report 'Security issue code: 0x03938745 (60000069)' (MigrosBank EBanking 8.2.x, Sparda Bank SecureApp 1.x)
by wine-bugs＠winehq.org Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=47061 Bug ID: 47061 Summary: Multiple E-Banking applications by KOBIL Systems GmbH crash on startup or report 'Security issue code: 0x03938745 (60000069)' (MigrosBank EBanking 8.2.x, Sparda Bank SecureApp 1.x) Product: Wine Version: 4.6 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation of bug 42391 Stable links for current installers: Sparda Bank SecureApp: https://web.archive.org/web/20190422125056/https://www.sparda.de/secureapp-… Corresponding VirusTotal scan: https://www.virustotal.com/gui/file/444c501236d5704e43ff5238a03b2c66a08eeba… --- MigrosBank EBanking app: https://web.archive.org/web/20190422124354/https://download.migrosbank.ch/m… Corresponding VirusTotal scan: https://www.virustotal.com/gui/file/9cd93cc70c6a8b24dbf47a3d20c9a1ed5f63414… --- Trace log: --- snip --- $ pwd /home/focht/.wine/drive_c/users/focht/Application Data/Sparda/AST-Client $ WINEDEBUG=+seh,+relay wine ./SpardaSecureApp.exe >>log.txt 2>&1 ... 003a:Ret KERNEL32.__wine_kernel_init() retval=7b472944 ret=7bc668b7 ... 003a:Call TLS callback (proc=0x20010530,module=0x20000000,reason=PROCESS_ATTACH,reserved=0) 003a:Call KERNEL32.VirtualAlloc(00000000,00000006,00003000,00000004) ret=2001256a 003a:Ret KERNEL32.VirtualAlloc() retval=00340000 ret=2001256a 003a:Call KERNEL32.VirtualAlloc(00000000,00000017,00003000,00000004) ret=2001258d 003a:Ret KERNEL32.VirtualAlloc() retval=00350000 ret=2001258d 003a:Call KERNEL32.GetModuleHandleA(00340000 "ntdll") ret=20012652 003a:Ret KERNEL32.GetModuleHandleA() retval=7bc10000 ret=20012652 003a:Call KERNEL32.GetProcAddress(7bc10000,00350000 "NtSetInformationThread") ret=20012659 003a:Ret KERNEL32.GetProcAddress() retval=7bc24870 ret=20012659 003a:Call KERNEL32.VirtualFree(00340000,00000000,00008000) ret=2001266a 003a:Ret KERNEL32.VirtualFree() retval=00000001 ret=2001266a 003a:Call KERNEL32.VirtualFree(00350000,00000000,00008000) ret=20012688 003a:Ret KERNEL32.VirtualFree() retval=00000001 ret=20012688 003a:Call ntdll.NtSetInformationThread(fffffffe,00000011,00000000,00000000) ret=200126c8 003a:Ret ntdll.NtSetInformationThread() retval=00000000 ret=200126c8 003a:Call ntdll.NtReadVirtualMemory(ffffffff,20000028,0033e434,00000002,0033e42c) ret=2001277b 003a:Ret ntdll.NtReadVirtualMemory() retval=00000000 ret=2001277b ... 003a:Call KERNEL32.VirtualProtect(1ffb0000,00000005,00000020,0033e384) ret=20014840 003a:Ret KERNEL32.VirtualProtect() retval=00000001 ret=20014840 003a:Call KERNEL32.VirtualProtect(1ffa0000,0000000a,00000020,0033e380) ret=2001484f 003a:Ret KERNEL32.VirtualProtect() retval=00000001 ret=2001484f 003a:Call KERNEL32.FlushInstructionCache(ffffffff,1ffa0000,0000000a) ret=20014860 003a:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=20014860 003a:Call KERNEL32.VirtualProtect(7bc206ac,00000005,00000040,0033e40c) ret=20014997 003a:Ret KERNEL32.VirtualProtect() retval=00000001 ret=20014997 003a:Call ntdll.RtlMoveMemory(7bc206ac,00360021,00000005) ret=200149a4 003a:Ret ntdll.RtlMoveMemory() retval=7bc206ac ret=200149a4 003a:Call KERNEL32.VirtualProtect(7bc206ac,00000005,00000020,0033e40c) ret=200149b4 003a:Ret KERNEL32.VirtualProtect() retval=00000001 ret=200149b4 003a:Call KERNEL32.FlushInstructionCache(ffffffff,7bc206ac,00000005) ret=200149c4 003a:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=200149c4 003a:Call ntdll.LdrRegisterDllNotification(00000000,20010d80,00000000,20076e5c) ret=2001116a 003a:Ret ntdll.LdrRegisterDllNotification() retval=00000000 ret=2001116a 003a:Call KERNEL32.TlsAlloc() ret=200111dc 003a:Ret KERNEL32.TlsAlloc() retval=00000002 ret=200111dc 003a:Call KERNEL32.VirtualAlloc(00000000,000001f4,00001000,00000004) ret=20011217 003a:Ret KERNEL32.VirtualAlloc() retval=00370000 ret=20011217 003a:Call KERNEL32.VirtualFree(00370000,00000000,00008000) ret=2001129d 003a:Ret KERNEL32.VirtualFree() retval=00000001 ret=2001129d 003a:Call KERNEL32.VirtualAlloc(00000000,00000030,00001000,00000004) ret=20014b0b 003a:Ret KERNEL32.VirtualAlloc() retval=00370000 ret=20014b0b 003a:Call KERNEL32.VirtualFree(00370000,00000000,00008000) ret=20014ab4 003a:Ret KERNEL32.VirtualFree() retval=00000001 ret=20014ab4 003a:Call KERNEL32.GetProcAddress(7bc10000,2006cc74 "_snwprintf") ret=200136f7 003a:Ret KERNEL32.GetProcAddress() retval=7bc78380 ret=200136f7 003a:Call KERNEL32.GetProcAddress(7b420000,2006cd44 "FatalAppExitW") ret=2001374a 003a:Ret KERNEL32.GetProcAddress() retval=7b42575c ret=2001374a 003a:Call KERNEL32.GetModuleHandleW(00000000) ret=2000a477 003a:Ret KERNEL32.GetModuleHandleW() retval=20000000 ret=2000a477 003a:Call KERNEL32.ReadProcessMemory(ffffffff,2000002e,0033dfa8,00000004,0033dfa4) ret=2000a49d 003a:Ret KERNEL32.ReadProcessMemory() retval=00000001 ret=2000a49d 003a:Call KERNEL32.GetModuleHandleW(00000000) ret=2000a4ba 003a:Ret KERNEL32.GetModuleHandleW() retval=20000000 ret=2000a4ba 003a:Call KERNEL32.ReadProcessMemory(ffffffff,20000024,0033dfa4,00000004,0033dfa0) ret=2000a4d4 003a:Ret KERNEL32.ReadProcessMemory() retval=00000001 ret=2000a4d4 003a:Call KERNEL32.ReadProcessMemory(ffffffff,0000002e,0033dfa8,00000004,0033dfa0) ret=2000a4f5 003a:Ret KERNEL32.ReadProcessMemory() retval=00000000 ret=2000a4f5 003a:Call KERNEL32.VirtualAlloc(00000000,00000064,00001000,00000004) ret=2001376f 003a:Ret KERNEL32.VirtualAlloc() retval=00370000 ret=2001376f 003a:Call KERNEL32.FatalAppExitW(00000000,0033dfc8 L"Security issue code: 0x03938745 (60000069)") ret=2001379b 003a:warn:seh:FatalAppExitW AppExit 003a:err:seh:FatalAppExitW L"Security issue code: 0x03938745 (60000069)" ... --- snip --- The protection code doesn't use Win32 API to resolve functions hence one needs to debug here. --- snip --- ... 20011276 | E8 9592FFFF | call spardasecureapp.2000A510 | find kernel32.dll 2001127B | A3 EC6D0720 | mov dword ptr ds:[20076DEC],eax | via PEB_LDR_DATA 20011280 | 8B55 FC | mov edx,dword ptr ss:[ebp-4] | "LoadAppInitDlls" 20011283 | 8BC8 | mov ecx,eax | 20011285 | E8 E694FFFF | call spardasecureapp.2000A770 | resolve API 2001128A | 68 00800000 | push 8000 | 2001128F | 6A 00 | push 0 | 20011291 | 57 | push edi | 20011292 | A3 AC6E0720 | mov dword ptr ds:[20076EAC],eax | 20011297 | FF15 CCD00420 | call dword ptr ds:[2004D0CC] | VirtualFree() 2001129D | 6A 01 | push 1 | ... --- snip --- -> it wants 'kernel32.LoadAppInitDlls' Bunch of API it wants to resolve and hook: --- snip --- ... 00360000 4B 69 55 73 65 72 41 70 63 44 69 73 70 61 74 63 KiUserApcDispatc 00360010 68 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00 her............. 00360020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00360030 00 00 4E 74 43 6F 6E 74 69 6E 75 65 00 00 00 00 ..NtContinue.... 00360040 00 00 00 00 00 00 00 00 00 00 00 00 4C 64 72 4C ............LdrL 00360050 6F 61 64 44 6C 6C 00 00 00 00 00 00 00 00 00 00 oadDll.......... 00360060 00 00 00 00 00 00 52 74 6C 4E 74 53 74 61 74 75 ......RtlNtStatu 00360070 73 54 6F 44 6F 73 45 72 72 6F 72 00 00 00 00 00 sToDosError..... 00360080 00 00 00 00 00 00 00 4C 6F 61 64 41 70 70 49 6E .......LoadAppIn 00360090 69 74 44 6C 6C 73 00 00 00 00 00 00 00 00 00 00 itDlls.......... 003600A0 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 64 72 .............Ldr 003600B0 52 65 67 69 73 74 65 72 44 6C 6C 4E 6F 74 69 66 RegisterDllNotif 003600C0 69 63 61 74 69 6F 6E 00 00 00 00 00 00 00 00 00 ication......... 003600D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 003600E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4C 64 ..............Ld 003600F0 72 55 6E 72 65 67 69 73 74 65 72 44 6C 6C 4E 6F rUnregisterDllNo 00360100 74 69 66 69 63 61 74 69 6F 6E 00 00 00 00 00 00 tification...... 00360110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ... --- snip --- Wine source: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/kernel32/kernel32.sp… --- snip --- 1044 # @ stub LoadAppInitDlls --- snip --- With an empty stub added, the app successfully executes the TLS callback and the real entry point is executed - only to run into next problem ;-) Tidbit: The 'AppInit_DLLs' feature is described here: https://support.microsoft.com/en-us/help/197571/working-with-the-appinit-dl… That's another way of having dlls automatically injected into every process. Most likely introduced by MS to support the malware industry ... j/k (or not?) ;-) $ sha1sum spardasecureapp_p.exe d579216a3a61555c68a75636893216b8a4233737 spardasecureapp_p.exe $ du -sh spardasecureapp_p.exe 9.6M spardasecureapp_p.exe $ wine --version wine-4.6-108-g9d7d68747b 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 7

[Bug 48473] New: kernelbase WaitNamedPipeW contains non-null terminated string, causing garbage output in trace logs
by WineHQ Bugzilla Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=48473 Bug ID: 48473 Summary: kernelbase WaitNamedPipeW contains non-null terminated string, causing garbage output in trace logs Product: Wine Version: 5.0-rc5 Hardware: x86-64 OS: Linux Status: NEW Severity: trivial Priority: P2 Component: kernelbase Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, as it says. --- snip --- ... 003b:Call KERNEL32.WaitNamedPipeW(0022d770 L"\\\\.\\pipe\\{49BD2028-1523-11D1-AD79-00C04FD8FDFF}",ffffffff) ret=00382fd4 003b:Call ntdll.RtlDosPathNameToNtPathName_U(0022d770 L"\\\\.\\pipe\\{49BD2028-1523-11D1-AD79-00C04FD8FDFF}",0022d318,00000000,00000000) ret=7b04bacb 003b:Ret ntdll.RtlDosPathNameToNtPathName_U() retval=00000001 ret=7b04bacb 003b:Call ntdll._wcsnicmp(023bd510 L"\\??\\pipe\\{49BD2028-1523-11D1-AD79-00C04FD8FDFF}",7b0735a0 L"\\??\\PIPE\\\6157\7469\614e\656d\5064\7069\5765\2500\2073\7830\3025\7838\n",00000009) ret=7b04baf7 003b:Ret ntdll._wcsnicmp() retval=00000000 ret=7b04baf7 ... --- snip --- The trace log contains garbage characters because the string is not NULL terminated. Technically there is nothing wrong here - but still it would make the log output less suspicious (uninitialized/corrupted memory). Wine source: https://source.winehq.org/git/wine.git/blob/0cbadb716ddaeb016ffe14deae2aace… --- snip --- 1337 BOOL WINAPI DECLSPEC_HOTPATCH WaitNamedPipeW( LPCWSTR name, DWORD timeout ) 1338 { 1339 static const WCHAR leadin[] = {'\\','?','?','\\','P','I','P','E','\\'}; 1340 NTSTATUS status; 1341 UNICODE_STRING nt_name, pipe_dev_name; 1342 FILE_PIPE_WAIT_FOR_BUFFER *pipe_wait; 1343 IO_STATUS_BLOCK iosb; 1344 OBJECT_ATTRIBUTES attr; 1345 ULONG wait_size; 1346 HANDLE pipe_dev; 1347 1348 TRACE( "%s 0x%08x\n", debugstr_w(name), timeout ); 1349 1350 if (!RtlDosPathNameToNtPathName_U( name, &nt_name, NULL, NULL )) return FALSE; 1351 1352 if (nt_name.Length >= MAX_PATH * sizeof(WCHAR) || 1353 nt_name.Length < sizeof(leadin) || 1354 wcsnicmp( nt_name.Buffer, leadin, ARRAY_SIZE( leadin )) != 0) 1355 { 1356 RtlFreeUnicodeString( &nt_name ); 1357 SetLastError( ERROR_PATH_NOT_FOUND ); 1358 return FALSE; 1359 } 1360 ... 1399 } --- snip --- Line 1354, 'leadin' is not NULL terminated. $ wine --version wine-5.0-rc5 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.

1 4

[Bug 33317] New: Python error Fatal Python error: buffer overflow in getpathp.c's joinpath() when executing.
by wine-bugs＠winehq.org Aug. 15, 2020

Aug. 15, 2020

http://bugs.winehq.org/show_bug.cgi?id=33317 Bug #: 33317 Summary: Python error Fatal Python error: buffer overflow in getpathp.c's joinpath() when executing. Product: Wine Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: andrew.thomas(a)hpcwales.co.uk Classification: Unclassified Created attachment 44067 --> http://bugs.winehq.org/attachment.cgi?id=44067 Lwsn output from running under wine Wine Version : wine64 --version wine-1.5.25 (64 Bit version) GCC Version : gcc --version gcc (GCC) 4.6.2 Python Version : python --version Python 2.7.3 Operating Systems Used: cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) I have also tried on : cat /etc/redhat-release CentOS release 5.5 (Final) Program trying to run lwsn.exe (network render module part of Lightwave : https://www.lightwave3d.com/ ). 30 Day trial available. Command used: wine lwsn.exe -3 -cLWEXT11-64.CFG -d"z:\home\andy.thomas\Atticus" Scenes\black.lws 1 1 Problem, I compiled wine and setup lwsn.exe in accordance with this article: http://lordtangent.blogspot.co.uk/2007/01/running-lightwave-screamernet-lws… Initially it worked fine when running from the command line. I then wrapped it up in a batch script to be sent to our Linux cluster but got a Python error message : Fatal Python error: buffer overflow in getpathp.c's joinpath() I tried to execute interactively on the cluster and this worked fine but when executed from a script it gives the above error. I launched a forum post (as I a haven't done much troubleshooting with wine) : http://forum.winehq.org/viewtopic.php?f=8&t=18632 I have tried the recommendations but had no success. I re-compiled wine with the above gcc compiler and a more up to date version of Python but I can no longer execute on the command line. I now get the Python error regardless of how I execute the command. Any help would be greatly appreciated. If you need any further debugging please let me know. -- 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 42474] New: unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCombineEx
by wine-bugs＠winehq.org Aug. 15, 2020

Aug. 15, 2020

https://bugs.winehq.org/show_bug.cgi?id=42474 Bug ID: 42474 Summary: unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCombineEx Product: Wine Version: 2.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: api-ms-win-* Assignee: wine-bugs(a)winehq.org Reporter: anonymous.maarten(a)gmail.com Distribution: --- Hey, python 3.6 (32- and 64-bit) needs the unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCombineEx URL: https://www.python.org/ftp/python/3.6.0/python-3.6.0-embed-amd64.zip $ du -b python-3.6.0-embed-amd64.zip 6925798 python-3.6.0-embed-amd64.zip $ shasum python-3.6.0-embed-amd64.zip 37bf20dcf39dfca096b11d29865202229a8fcb42 python-3.6.0-embed-amd64.zip $ wine --version wine-2.0 (Staging) Running Fedora 24 -- 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 38