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

[Bug 46156] New: Multiple applications from Windows 7-10 crash on unimplemented function slc.dll.SLOpen
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=46156 Bug ID: 46156 Summary: Multiple applications from Windows 7-10 crash on unimplemented function slc.dll.SLOpen Product: Wine Version: 3.20 Hardware: aarch64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: slc Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation of bug 46143 Likely also present on x86_64 arch. --- snip --- $ WINEDEBUG=+seh,+loaddll,+process,+relay,+ntdll wine64 ./gatherosstate.exe >>log.txt 2>&1 ... 002b:Call KERNEL32.LoadLibraryExW(14000aaa0 L"SLC.DLL",00000000,00000000) ret=140044618 ... 002b:trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\slc.dll" at 0x7f87a70000: builtin 002b:Call PE DLL (proc=0x7f87a8c5a4,module=0x7f87a70000 L"slc.dll",reason=PROCESS_ATTACH,res=(nil)) 002b:Call KERNEL32.DisableThreadLibraryCalls(7f87a70000) ret=7f87a8c58c 002b:Ret KERNEL32.DisableThreadLibraryCalls() retval=00000001 ret=7f87a8c58c 002b:Ret PE DLL (proc=0x7f87a8c5a4,module=0x7f87a70000 L"slc.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 002b:Ret KERNEL32.LoadLibraryExW() retval=7f87a70000 ret=140044618 002b:Call KERNEL32.GetLastError() ret=140032274 002b:Ret KERNEL32.GetLastError() retval=0000007e ret=140032274 002b:Call KERNEL32.FlushInstructionCache(ffffffffffffffff,00356840,00000080) ret=14003229c 002b:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=14003229c 002b:Call KERNEL32.GetLastError() ret=140031de0 002b:Ret KERNEL32.GetLastError() retval=0000007e ret=140031de0 002b:Call KERNEL32.FlushInstructionCache(ffffffffffffffff,0035de40,00000040) ret=140031e08 002b:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=140031e08 002b:Call KERNEL32.GetProcAddress(7f87a70000,14000aab0 "SLOpen") ret=1400446c0 002b:Ret KERNEL32.GetProcAddress() retval=7f87a8c090 ret=1400446c0 002b:Call KERNEL32.GetLastError() ret=140031de0 002b:Ret KERNEL32.GetLastError() retval=0000007e ret=140031de0 002b:Call KERNEL32.FlushInstructionCache(ffffffffffffffff,00358200,00000040) ret=140031e08 002b:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=140031e08 002b:Call KERNEL32.GetProcAddress(7f87a70000,14000aab8 "SLClose") ret=140044760 002b:Ret KERNEL32.GetProcAddress() retval=7f87a8be28 ret=140044760 002b:Call KERNEL32.GetLastError() ret=140031de0 002b:Ret KERNEL32.GetLastError() retval=0000007e ret=140031de0 002b:Call KERNEL32.FlushInstructionCache(ffffffffffffffff,00355d40,00000040) ret=140031e08 002b:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=140031e08 002b:Call KERNEL32.GetProcAddress(7f87a70000,14000aac0 "SLGetLicensingStatusInformation") ret=1400447a0 002b:Ret KERNEL32.GetProcAddress() retval=7f87a8bf40 ret=1400447a0 002b:Call KERNEL32.GetLastError() ret=140031de0 002b:Ret KERNEL32.GetLastError() retval=0000007e ret=140031de0 002b:Call KERNEL32.FlushInstructionCache(ffffffffffffffff,00350b40,00000040) ret=140031e08 002b:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=140031e08 002b:Call KERNEL32.GetProcAddress(7f87a70000,14000aae0 "SLGetProductSkuInformation") ret=1400447e0 002b:Ret KERNEL32.GetProcAddress() retval=7f87a8bfcc ret=1400447e0 002b:Call KERNEL32.GetLastError() ret=140031de0 002b:Ret KERNEL32.GetLastError() retval=0000007e ret=140031de0 002b:Call KERNEL32.FlushInstructionCache(ffffffffffffffff,0035dac0,00000040) ret=140031e08 002b:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=140031e08 002b:Call KERNEL32.GetProcAddress(7f87a70000,14000ab00 "SLGetSLIDList") ret=140044820 002b:Ret KERNEL32.GetProcAddress() retval=7f87a8c004 ret=140044820 002b:Call KERNEL32.RaiseException(80000100,00000001,00000002,0022f720) ret=7f87a8c744 002b:trace:seh:raise_exception info[0]=0000007f87a8c758 002b:trace:seh:raise_exception info[1]=0000007f87a8c9fb wine: Call from 0x7bcd0224 to unimplemented function slc.dll.SLOpen, aborting 002b:trace:seh:call_stack_handlers calling handler at 0x7b4d6494 code=80000100 flags=1 wine: Unimplemented function slc.dll.SLOpen called at address 0x7bcd0224 (thread 002b), starting debugger... ...Register dump: ARM64 EL0t Mode Pc:000000007bcd0224 Sp:000000000022f1e0 Lr:000000007bcd2530 Cpsr:20000000(--C-) x0: 000000000022f208 x1: 000000000022f720 x2: 0000000000000001 x3: 000000000022f5c0 x4: 000000000022f730 x5: 000000000022f5f0 x6: 0000007f87a8c758 x7: 0000007f87a8c9fb x8: 000000000022f208 x9: 000000000022f208 x10:0000000000000008 x11:0000000000000002 x12:0000000000000004 x13:0000000000000000 x14:ffffffffffffffaa x15:000000007bd25a60 ip0:000000007b674000 ip1:0000007f881d0dd0 x18:000000007ffd8000 x19:000000000022f700 x20:0000007f87a70000 x21:0000007f87a8c090 x22:0000007f87a8bf40 x23:000000000022f848 x24:0000007f87a8be28 x25:0000000000000000 x26:0000000140094000 x27:000000014000f000 x28:000000007b4a2cc4 Fp:000000000022f5b0 ... Backtrace: =>0 0x000000007bcd0224 RtlCaptureContext+0xa4() in ntdll (0x000000000022f5b0) 1 0x000000007bcd2530 RtlRaiseException+0x33(rec=0x22f5c0) [/home/focht/projects/wine/mainline-src/dlls/ntdll/signal_arm64.c:995] in ntdll (0x000000000022f5b0) 2 0x000000007bcd2530 RtlRaiseException+0x33(rec=0x22f720) [/home/focht/projects/wine/mainline-src/dlls/ntdll/signal_arm64.c:995] in ntdll (0x000000000022f670) 3 0x000000007b466ccc RaiseException+0xc7(code=0, flags=0x7bcb25a0, nbargs=0, args=0x8000010000000001) [/home/focht/projects/wine/mainline-src/dlls/kernel32/except.c:85] in kernel32 (0x000000000022f680) 4 0x000000007bcb25a0 call_entry_point+0x8f() in ntdll (0x000000000035dae8) 5 0x0000007f87a70000 in slc<elf> (+0x4fff) (0x000000000035dae8) 0x000000007bcd0224 RtlCaptureContext+0xa4 in ntdll: be_arm64_disasm_one_insn: not done Modules: Module Address Debug info Name (20 modules) ELF 7b400000- 7b826000 Dwarf kernel32<elf> \-PE 7b420000- 7b826000 \ kernel32 ELF 7bc00000- 7bd45000 Dwarf ntdll<elf> \-PE 7bc20000- 7bd45000 \ ntdll ELF 7c000000- 7c004000 Deferred <wine-loader> PE 140000000- 140099000 Deferred gatherosstate ELF 7f87a6b000- 7f87a90000 Dwarf slc<elf> \-PE 7f87a70000- 7f87a90000 \ slc ... ELF 7f884b7000- 7f884e9000 Deferred ld-linux-aarch64.so.1 ELF 7f884ea000- 7f884eb000 Deferred [vdso].so Threads: process tid prio (all id:s are in hex) ... 0000002a (D) Z:\home\focht\projects\woa-winrt\win10apps\arm64\gatherosstate.exe 0000002b 0 <== System information: Wine build: wine-3.20-116-g7628b7b40d Platform: arm64 Version: Windows 7 Host system: Linux Host version: 4.18.14-yocto-standard --- snip --- Wine source: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/slc/slc.spec#l33 --- snip --- 33 @ stub SLOpen --- snip --- Microsoft docs: https://docs.microsoft.com/en-us/windows/desktop/api/slpublic/nf-slpublic-s… 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 5

[Bug 40208] New: Steup installation of CEGID BUISINESS LINE failed.
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=40208 Bug ID: 40208 Summary: Steup installation of CEGID BUISINESS LINE failed. Product: Wine Version: 1.9.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: christian.briard(a)gmx.com Distribution: --- Created attachment 53723 --> https://bugs.winehq.org/attachment.cgi?id=53723 MSI log Executing an installation of CEGID BUISINESS LINE failed with a log text (see attached files). "Install: C:\windows\System32\msiexec.exe /q /i "Z:\home\cbriard\CBL\PRODUCTS\AIDEBL.MSI" INSTALLDIR="C:\Program Files\Cegid\Cegid Business Line\" /norestart Install : 1603 - C:\windows\System32\msiexec.exe - Erreur en exécution du programme" Here enclosed a trace file to. Any idea of what is going wrong ? Christian. -- 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 38402] New: glDebugMessageCallback is broken
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=38402 Bug ID: 38402 Summary: glDebugMessageCallback is broken Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)winehq.org Reporter: chris.kcat(a)gmail.com Distribution: --- According to the KHR_debug extension spec, the function glDebugMessageCallback takes a function pointer callback with the type: typedef void (APIENTRY *GLDEBUGPROC)(GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar* message, const void* userParam); https://www.opengl.org/registry/specs/KHR/debug.txt In particular, it notes that the function callback uses the same calling convention as the other GL functions. The problem is that on Windows, GL uses the stdcall calling convention, while on Linux it uses cdecl. Wine's glDebugMessageCallback thunk passes the callback through as-is, so the system's libGL tries to call an stdcall function as though it was cdecl, causing it to crash upon returning. Another problem is that the spec says: "When DEBUG_OUTPUT_SYNCHRONOUS is disabled, the driver is optionally allowed to concurrently call the debug callback routine from potentially multiple threads, including threads that the context that generated the message is not currently bound to." meaning the callback can be called on threads other than the one OpenGL is being used on. This is a problem because it may be called on one or more internal driver threads that were not created using the Windows API, and if the callback function tries to do anything that relies on Windows-related thread information, it won't be there. -- 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 20

[Bug 46210] New: explorer /desktop leaks atoms from DDE interface
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=46210 Bug ID: 46210 Summary: explorer /desktop leaks atoms from DDE interface Product: Wine Version: 3.20 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: explorerframe Assignee: wine-bugs(a)winehq.org Reporter: ralf.habacker(a)freenet.de Distribution: --- explorer /desktop, started by wine as background process, initiate a DDE interface (see https://github.com/wine-mirror/wine/blob/master/programs/explorer/desktop.c… and https://github.com/wine-mirror/wine/blob/master/dlls/shell32/dde.c#L483 for details), but the DDE interface is not been free'd after main loop exit (https://github.com/wine-mirror/wine/blob/master/programs/explorer/desktop.c…) resulting in leaked atoms. On the first run the following DDE related atoms are created: c018: ref=2 pinned=N hash=14 "Folders" c019: ref=1 pinned=N hash=18 "Folders(0x 23)" c01b: ref=2 pinned=N hash=17 "Progman" c01c: ref=1 pinned=N hash=17 "Progman(0x 23)" c01d: ref=2 pinned=N hash=29 "Shell" c01e: ref=1 pinned=N hash=23 "Shell(0x 23)" on the next start the following atoms are added and so one c01f: ref=1 pinned=N hash=21 "Folders(0x 44)" c027: ref=1 pinned=N hash=22 "Progman(0x 44)" c028: ref=1 pinned=N hash=26 "Shell(0x 44)" Because the DDE interface use atoms unique for each session, each run leaks three atoms -- 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 46040] New: every time i launch any windows .exe it give me some random error ive never seen before
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=46040 Bug ID: 46040 Summary: every time i launch any windows .exe it give me some random error ive never seen before Product: Wine Version: 3.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: anubis2497(a)gmail.com Distribution: --- Created attachment 62618 --> https://bugs.winehq.org/attachment.cgi?id=62618 backtrace random bug -- 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 45913] New: tchar.h: using the macro _sntprintf leads to an undefined reference to snwprintf; macro should resolve to _snwprintf
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=45913 Bug ID: 45913 Summary: tchar.h: using the macro _sntprintf leads to an undefined reference to snwprintf; macro should resolve to _snwprintf Product: Wine Version: unspecified Hardware: arm OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winelib Assignee: wine-bugs(a)winehq.org Reporter: contact(a)ivanchev.net Distribution: --- According to MSDN (https://msdn.microsoft.com/en-us/library/2ts7cx93.aspx) the following macro definition in tchar.h: #define _sntprintf WINE_tchar_routine(snprintf, snprintf, snwprintf) is missing an underscore at the beginning snwprintf #define _sntprintf WINE_tchar_routine(snprintf, snprintf, _snwprintf). -- 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 41419] New: Visio 2013 crashes with unimplemented function msvcp100.dll.? _GetCombinableSize@details@Concurrency@@YAIXZ
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=41419 Bug ID: 41419 Summary: Visio 2013 crashes with unimplemented function msvcp100.dll.?_GetCombinableSize(a)details@Concurrency@@ YAIXZ Product: Wine Version: 1.9.20 Hardware: x86-64 OS: Linux Status: NEW Severity: minor Priority: P2 Component: msvcp Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- wine: Call from 0x7b43b53c to unimplemented function msvcp100.dll.?_GetCombinableSize(a)details@Concurrency@@YAIXZ, aborting -- 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 46081] New: Multiple installers show readonly drives with broken size
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=46081 Bug ID: 46081 Summary: Multiple installers show readonly drives with broken size Product: Wine Version: 3.19 Hardware: x86 URL: https://web.archive.org/web/20171225133033if_/http://d ownload.microsoft.com/download/e/a/9/ea913c8b-51a7-41b 7-8697-9f0d0a7274aa/ExcelViewer.exe OS: Linux Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 62711 --> https://bugs.winehq.org/attachment.cgi?id=62711 Screenshot See screenshot. The readonly drives probably should not even be listed. Note that this installer extracts and runs a msi file. -- 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 45588] New: .Net Framework 4.5.2 (WPF) requires windowscodecs.dll.IWICPixelFormatInfo_GetChannelCount_Proxy
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=45588 Bug ID: 45588 Summary: .Net Framework 4.5.2 (WPF) requires windowscodecs.dll.IWICPixelFormatInfo_GetChannelCount_ Proxy Product: Wine Version: 3.13 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: windowscodecs Assignee: wine-bugs(a)winehq.org Reporter: jp7677(a)gmail.com Distribution: --- "Content Manager" (https://acstuff.ru/app/ https://assettocorsa.club/index.php?q=content-manager.html) is an alternative launcher for Assetto Corsa. That one requires/uses WPF from .Net Framework 4.5.2. The launcher works surprisingly well and much better that the original Assetto Corsa launcher which I never got to work. Anyway, "Content Manager" works fine in wine once .Net 4.5.2 is installed, though with several actions, like selecting a track, the program crashes with: wine: Call from 0x7b43d85b to unimplemented function windowscodecs.dll.IWICPixelFormatInfo_GetChannelCount_Proxy, aborting Looking at https://github.com/wine-mirror/wine/blob/master/dlls/windowscodecs/windowsc… this method is indeed not implemented in the wine implementation of windowscodecs. It would be nice if this method could be implemented. I don't know if IWICPixelFormatInfo_GetBitsPerPixel_Proxy and IWICPixelFormatInfo_GetChannelMask_Proxy are also needed, but could imagine that this is the case. PS: Installing the native version of windowscodecs is a somewhat of a work-around. The application does no longer crash, but then a lot of images are no longer displayed correctly (looks like transparent is displayed as white). Kind 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 15

[Bug 44229] New: Visual C++ 1.51 can't add files to project ( GetOpenFileName16() doesn't support custom templates or hooks)
by wine-bugs＠winehq.org March 3, 2019

March 3, 2019

https://bugs.winehq.org/show_bug.cgi?id=44229 Bug ID: 44229 Summary: Visual C++ 1.51 can't add files to project (GetOpenFileName16() doesn't support custom templates or hooks) Product: Wine Version: 3.0-rc3 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comdlg32 Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Regression SHA1: 424472c20d8059057277ae13a0ffe5c51a818e52 Distribution: --- The Project -> Edit menu is missing the "Files in Project" box as well as the Add / Add All / Delete buttons. This is because we don't support custom templates or hooks anymore: 0031:fixme:commdlg:GetOpenFileName16 custom templates no longer supported, using default 0031:fixme:commdlg:GetOpenFileName16 custom hook 0x16670010 no longer supported While hooks would probably be simple enough to implement, templates will be much more difficult and will probably require significant duplication of code from user.exe16:dialog.c. Is there a reason to implement commdlg on top of comdlg32 besides avoiding duplication? -- 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