https://bugs.winehq.org/show_bug.cgi?id=38987
Bug ID: 38987 Summary: tlReader crashes when searching dictionary Product: Wine Version: 1.7.47 Hardware: x86 URL: http://tshwanedje.com/downloads/download.php?app=tlRea der OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: leftmostcat@gmail.com Distribution: ---
Created attachment 51942 --> https://bugs.winehq.org/attachment.cgi?id=51942 log with warn+all
Using the Manx-English dictionary at http://tshwanedje.com/downloads/files/ and the latest version of tlReader from the download URL provided, opening the dictionary and typing in the search box causes the application to crash and attempt to report the issue.
https://bugs.winehq.org/show_bug.cgi?id=38987
Sean Burke leftmostcat@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #1 from Austin English austinenglish@gmail.com --- Please don't attach logs with warn+all unless asked for, it's usually not terribly helpful, just the normal output without setting WINEDEBUG is fine for initial upload.
There's no backtrace in your log, could you disable the crash dialog and upload a new log with the backtrace?
https://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #2 from Sean Burke leftmostcat@gmail.com --- Created attachment 51951 --> https://bugs.winehq.org/attachment.cgi?id=51951 log with no WINEDEBUG
Sorry about that, figured it was better than nothing. Uploading a log without WINEDEBUG, though it shows nothing serious that I can tell. I looked for a way to disable the report dialog, but see none.
While looking for settings, I did change the View > HTML window provider from the default wxWebKit to CEF3, which prevents the crash.
https://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #3 from Bruno Jesus 00cpxxx@gmail.com --- If you read the log the first 2 lines will be:
fixme:winediag:start_process Wine Staging 1.7.47 is a testing version containing experimental patches. fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com (instead of winehq.org).
Can you reproduce the issue using plain wine instead of wine-staging?
https://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #4 from Sean Burke leftmostcat@gmail.com --- (In reply to Bruno Jesus from comment #3)
Can you reproduce the issue using plain wine instead of wine-staging?
The bug has been present for some time (at least since ca. 1.7.35) when compiling from git. It presents in precisely the same fashion.
https://bugs.winehq.org/show_bug.cgi?id=38987
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #5 from super_man@post.com --- (In reply to Sean Burke from comment #4)
(In reply to Bruno Jesus from comment #3)
Can you reproduce the issue using plain wine instead of wine-staging?
The bug has been present for some time (at least since ca. 1.7.35) when compiling from git. It presents in precisely the same fashion.
I cant even get the program started. It opens and closes itself. Could be program update or wine. Hard to say.
wine 1.9.1
https://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #6 from super_man@post.com --- (In reply to super_man from comment #5)
(In reply to Sean Burke from comment #4)
(In reply to Bruno Jesus from comment #3)
Can you reproduce the issue using plain wine instead of wine-staging?
The bug has been present for some time (at least since ca. 1.7.35) when compiling from git. It presents in precisely the same fashion.
I cant even get the program started. It opens and closes itself. Could be program update or wine. Hard to say.
wine 1.9.1
It seems that the program can be started with wine-staging but it fails with pure wine. Also the issue reported is still valid against 1.9.6-staging. It crashes while doing a search.
https://bugs.winehq.org/show_bug.cgi?id=38987
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #7 from winetest@luukku.com --- The same wine 2.0rc6 and staging 2.0rc5.
https://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #8 from winetest@luukku.com --- The program doesn't start with wine-2.9-git, but does with wine-staging 2.9.
But also staging fails to do the search.
Tldreader version at the time
tlReader_9.1.0.1752.exe
So still valid.
https://bugs.winehq.org/show_bug.cgi?id=38987
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x@gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #9 from Louis Lenders xerox.xerox2000x@gmail.com --- Confirming. Still present in wine-3.4
sha1sum tlReader_10.1.0.2004.exe 0c09fb0d0d5efc89cb8ff5bc12 ce15347e04a63e tlReader_10.1.0.2004.exe
No idea where the error comes from, i`ll attach last lines from debuglog before error window comes up
https://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #10 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 60957 --> https://bugs.winehq.org/attachment.cgi?id=60957 last 15000 lines before error window
last 15000 lines before error window
https://bugs.winehq.org/show_bug.cgi?id=38987
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Summary|tlReader crashes when |tlReader 10.x crashes when |searching dictionary |searching dictionary
--- Comment #11 from Anastasius Focht focht@gmx.net --- Hello folks,
the crash on startup is bug 32342
The wxWigets font enumerator class isn't happy about the returned font facenames.
'winetricks -q corefonts' (or Arial font alone) prevents the crash.
--- snip --- $ pwd /home/focht/wineprefix32/drive_c/Program Files/tlReader
$ WINEDEBUG=+seh,+relay,+snoop wine ./tlReader.exe >>log.txt 2>&1 ... 002e:CALL wxmsw294u_core_vc_custom.?IsValidFacename@wxFontEnumerator@@SA_NABVwxString@@@Z(0032eee4) ret=041747e9 002e:CALL wxbase294u_vc_custom.?IsSameAs@wxString@@QBE_NPB_W_N@Z(00cade50,00000000) ret=00ac55fe ... 002e:Call msvcr100._wcsicmp(0636f040 L"Arial Unicode MS",06370c70 L"Ms Shell Dlg") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=fffffff4 ret=0092e371 ... 002e:Call msvcr100._wcsicmp(0636f040 L"Arial Unicode MS",06370c70 L"Ms Shell Dlg 2") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=fffffff4 ret=0092e371 ... 002e:RET wxbase294u_vc_custom.?IsSameAs@wxString@@QBE_NPB_W_N@Z() retval=00000000 ret=00ac5611 002e:CALL wxbase294u_vc_custom.?Index@wxArrayString@@QBEHABVwxString@@_N1@Z(0032eee4,00000000,00000000) ret=00ac5625 002e:Call msvcr100._wcsicmp(0636f3b0 L"Liberation Serif",0636f040 L"Arial Unicode MS") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=0000000b ret=0092e371 002e:Call msvcr100._wcsicmp(0636fe60 L"DejaVu Sans Mono",0636f040 L"Arial Unicode MS") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=00000003 ret=0092e371 002e:Call msvcr100._wcsicmp(0636f628 L"Khmer OS Content",0636f040 L"Arial Unicode MS") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=0000000a ret=0092e371 002e:Call msvcr100._wcsicmp(0636f190 L"Lohit Devanagari",0636f040 L"Arial Unicode MS") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=0000000b ret=0092e371 002e:Call msvcr100._wcsicmp(06370980 L"Montserrat Black",0636f040 L"Arial Unicode MS") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=0000000c ret=0092e371 002e:Call msvcr100._wcsicmp(06370a28 L"Montserrat Light",0636f040 L"Arial Unicode MS") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=0000000c ret=0092e371 002e:Call msvcr100._wcsicmp(06374a10 L"Noto Color Emoji",0636f040 L"Arial Unicode MS") ret=0092e371 002e:Ret msvcr100._wcsicmp() retval=0000000d ret=0092e371 002e:RET wxbase294u_vc_custom.?Index@wxArrayString@@QBEHABVwxString@@_N1@Z() retval=ffffffff ret=00ac5625 002e:RET wxmsw294u_core_vc_custom.?IsValidFacename@wxFontEnumerator@@SA_NABVwxString@@@Z() retval=ffffff00 ret=041747e9 002e:CALL wxbase294u_vc_custom.??1wxString@@QAE@XZ() ret=04174803 ... 002e:CALL jscore.?equalIgnoringCase@WTF@@YA_NPAVStringImpl@1@0@Z(81f18690,81f6b340,61af4562) ret=04137345 002e:RET jscore.?equalIgnoringCase@WTF@@YA_NPAVStringImpl@1@0@Z() retval=81f6b300 ret=04137345 002e:trace:seh:raise_exception code=c0000005 flags=0 addr=0x3cb56a4 ip=03cb56a4 tid=002e 002e:trace:seh:raise_exception info[0]=00000000 002e:trace:seh:raise_exception info[1]=00000000 002e:trace:seh:raise_exception eax=00000000 ebx=f1100401 ecx=00000000 edx=0636f400 esi=81f08320 edi=81f08370 002e:trace:seh:raise_exception ebp=81f50a40 esp=0032f010 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010212 002e:trace:seh:call_stack_handlers calling handler at 0x458e744 code=c0000005 flags=0 002e:trace:seh:call_stack_handlers handler at 0x458e744 returned 1 002e:trace:seh:call_stack_handlers calling handler at 0x458b668 code=c0000005 flags=0 002e:trace:seh:call_stack_handlers handler at 0x458b668 returned 1 --- snip --
https://github.com/wxWidgets/wxWidgets/blob/v2.9.4/src/common/fontenumcmn.cp...
$ sha1sum tlReader_10.1.0.2004.exe 0c09fb0d0d5efc89cb8ff5bc12ce15347e04a63e tlReader_10.1.0.2004.exe
$ du -sh tlReader_10.1.0.2004.exe 31M tlReader_10.1.0.2004.exe
$ wine --version wine-3.5
Regards
https://bugs.winehq.org/show_bug.cgi?id=38987
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|tlReader 10.x crashes when |tlReader 10.x crashes when |searching dictionary |searching dictionary | |(wxWidgets 2.9.4 | |questionable theming | |support detection via | |comctl32 v6 version | |resource) Component|-unknown |comctl32
--- Comment #12 from Anastasius Focht focht@gmx.net --- Hello folks again,
after working around bug 32342 the next crash:
--- snip --- $ pwd /home/focht/wineprefix32/drive_c/Program Files/tlReader
$ WINEDEBUG=+seh,+relay,+snoop wine ./tlReader.exe >>log.txt 2>&1 ... 002e:CALL wxmsw294u_core_vc_custom.?Get@wxUxThemeEngine@@SAPAV1@XZ(<unknown, check return>) ret=041c4873 002e:RET wxmsw294u_core_vc_custom.?Get@wxUxThemeEngine@@SAPAV1@XZ() retval=00000000 ret=041c4873 002e:trace:seh:raise_exception code=c0000005 flags=0 addr=0x41c4875 ip=041c4875 tid=002e 002e:trace:seh:raise_exception info[0]=00000000 002e:trace:seh:raise_exception info[1]=00000000 002e:trace:seh:raise_exception eax=00000000 ebx=134f60d8 ecx=81f1fc84 edx=04124c00 esi=134f7b30 edi=134f7b30 002e:trace:seh:raise_exception ebp=00000000 esp=0032f430 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210216 002e:trace:seh:call_stack_handlers calling handler at 0x45874cf code=c0000005 flags=0 002e:trace:seh:call_stack_handlers handler at 0x45874cf returned 1 002e:trace:seh:call_stack_handlers calling handler at 0x45873b8 code=c0000005 flags=0 --- snip ---
Disassembly of caller code:
--- snip --- ... 04084855 MOV DWORD PTR FS:[0],EAX 0408485B MOV EAX,DWORD PTR SS:[ESP+0EC] 04084862 MOV EDI,DWORD PTR SS:[ESP+0E8] 04084869 MOV DWORD PTR SS:[ESP+14],EAX 0408486D CALL DWORD PTR DS:[<&wxmsw294u_core_vc_custom.wxUxThemeEngine::Get>] 04084873 MOV EBP,EAX ; NULL 04084875 MOV ECX,DWORD PTR SS:[EBP] ; *boom* 04084878 PUSH OFFSET 0455D064 ; UNICODE "SCROLLBAR" 0408487D PUSH 0 0408487F CALL ECX ... --- snip ---
Caller module mapping:
--- snip --- Executable modules Base = 03670000 Size = 011B4000 (18563072.) Entry = 0434B2F9 Name = wxwebkit Type = File version = Static links = ADVAPI32, GDI32, gdiplus, icuin40, icuuc40, jscore, KERNEL32, libcairo-2, libcurl, libxml2, libxslt, MSVCP100, MSVCR100, ole32, SHLWAPI, sqlite3, USER32, USP10, VERSION, WINMM, WSOCK32, wxbase294u_vc_custom, wxmsw294u_core_vc_custom Path = C:\Program Files\tlReader\wxwebkit.dll --- snip ---
WxWidgets UxTheme code for the getter:
https://github.com/wxWidgets/wxWidgets/blob/v2.9.4/src/msw/uxtheme.cpp#L78
--- snip --- wxUxThemeEngine* wxUxThemeEngine::Get() { // we assume that themes are only used in the main thread hence no need for // critical section here if ( ms_isThemeEngineAvailable == -1 ) { // we're called or the first time, check if the themes are available ms_themeEngine = new wxUxThemeEngine; if ( !ms_themeEngine->Initialize() ) { // can't use themes, probably because the system doesn't support // them, don't do it again delete ms_themeEngine; ms_themeEngine = NULL;
ms_isThemeEngineAvailable = false; } else // initialized ok { ms_isThemeEngineAvailable = true; } }
return ms_themeEngine; } --- snip ---
The NULL ptr return resulted from this:
https://github.com/wxWidgets/wxWidgets/blob/v2.9.4/src/msw/uxtheme.cpp#L104
--- snip --- bool wxUxThemeEngine::Initialize() { if ( wxApp::GetComCtl32Version() < 600 ) { // not using theme-aware comctl32.dll anyhow, don't even try to use // themes return false; }
// we're prepared to handle the errors wxLogNull noLog;
if ( !m_dllUxTheme.Load(wxT("uxtheme.dll")) ) return false; --- snip ---
Most likely there is some missing check of uxtheme engine availability and the caller just does 'wxUxThemeEngine::Get()->foobar()'. One could argue that wxWidgets could have done better error handling here. In fact they do a lot of checks ... maybe one code path missed it.
The comctl32 dll version check seems kinda questionable though.
https://github.com/wxWidgets/wxWidgets/blob/v2.9.4/src/msw/app.cpp#L917
--- snip --- int wxApp::GetComCtl32Version() { // cache the result // // NB: this is MT-ok as in the worst case we'd compute s_verComCtl32 twice, // but as its value should be the same both times it doesn't matter static int s_verComCtl32 = -1;
if ( s_verComCtl32 == -1 ) { // we're prepared to handle the errors wxLogNull noLog;
// we don't want to load comctl32.dll, it should be already loaded but, // depending on the OS version and the presence of the manifest, it can // be either v5 or v6 and instead of trying to guess it just get the // handle of the already loaded version wxLoadedDLL dllComCtl32(wxT("comctl32.dll")); if ( !dllComCtl32.IsLoaded() ) { s_verComCtl32 = 0; return 0; }
// try DllGetVersion() for recent DLLs s_verComCtl32 = CallDllGetVersion(dllComCtl32);
// if DllGetVersion() is unavailable either during compile or // run-time, try to guess the version otherwise if ( !s_verComCtl32 ) { // InitCommonControlsEx is unique to 4.70 and later void *pfn = dllComCtl32.GetSymbol(wxT("InitCommonControlsEx")); if ( !pfn ) { // not found, must be 4.00 s_verComCtl32 = 400; } else // 4.70+ { // many symbols appeared in comctl32 4.71, could use any of // them except may be DllInstall() pfn = dllComCtl32.GetSymbol(wxT("InitializeFlatSB")); if ( !pfn ) { // not found, must be 4.70 s_verComCtl32 = 470; } else { // found, must be 4.71 or later s_verComCtl32 = 471; } } } }
return s_verComCtl32; } --- snip ---
There is proper manifest data in binaries, specifically common controls v6:
--- snip --- $ pwd /home/focht/wineprefix32/drive_c/Program Files/tlReader
$ grep -aPo '.{0,20}Microsoft.Windows.Common-Controls.{0,20}' *{.dll,.exe} DicLib.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" jscore.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" wxActiveX.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" wxbase294u_vc_custom.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" wxmsw294u_adv_vc_custom.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" wxmsw294u_core_vc_custom.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" wxmsw294u_html_vc_custom.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" wxmsw294u_stc_vc_custom.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" wxwebkit.dll: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" tlReader.exe: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" Uninstall.exe: type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" --- snip ---
Wine provides two variants of 'comctl32' as Windows does:
* v5 under traditional location -> 'C:\Windows\system32' (or WoW64 locations) * v6 under 'C:\Windows\WinSxS', available as a side-by-side assembly with theming support.
Corresponding trace log showing manifest is taken into account:
--- snip --- ... 0041:trace:actctx:get_manifest_in_module looking for res #0002 in module 0x9d0000 L"C:\Program Files\tlReader\wxmsw294u_core_vc_custom.dll" 0041:trace:actctx:parse_manifest parsing manifest loaded from (null) base dir (null) 0041:trace:actctx:parse_assembly_elem (0x32de24) 0041:trace:actctx:parse_assembly_identity_elem name=L"Microsoft.Windows.Common-Controls" version=6.0.0.0 arch=L"x86" 0041:trace:actctx:parse_dependent_assembly_elem adding name=L"Microsoft.Windows.Common-Controls" version=6.0.0.0 arch=L"x86" 0041:trace:actctx:lookup_assembly looking for name=L"Microsoft.Windows.Common-Controls" version=6.0.0.0 arch=L"x86" 0041:trace:ntdll:FILE_CreateFile handle=0x32e1f0 access=80100000 name=L"\??\C:\windows\winsxs\manifests" objattr=00000040 root=(nil) sec=(nil) io=0x32e1f4 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000021 ea=(nil).0x00000000 0041:trace:ntdll:FILE_CreateFile handle=0x32e1f0 access=80100000 name=L"\??\C:\windows\winsxs\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef.manifest" objattr=00000040 root=(nil) sec=(nil) io=0x32e1b0 alloc_size=(nil) attr=00000000 sharing=00000001 disp=1 options=00000010 ea=(nil).0x00000000 0041:trace:actctx:get_manifest_in_manifest_file loading manifest file L"\??\C:\windows\winsxs\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef.manifest" 0041:trace:ntdll:NtQueryInformationFile (0x24,0x32e1a0,0x32e1a8,0x00000008,0x00000014) 0041:trace:actctx:parse_manifest parsing manifest loaded from L"\??\C:\windows\winsxs\manifests\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef.manifest" base dir L"x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef" 0041:trace:actctx:parse_assembly_elem (0x32dce4) 0041:trace:actctx:parse_assembly_identity_elem name=L"Microsoft.Windows.Common-Controls" version=6.0.2600.2982 arch=L"x86" 0041:trace:actctx:parse_file_elem name=L"comctl32.dll" ... 0041:trace:module:find_dll_file found L"C:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef\comctl32.dll" for L"comctl32.dll" 0041:trace:actctx:RtlFindActivationContextSectionString 00000001 (null) 2 L"comctl32.dll" 0x32d538 0041:trace:actctx:RtlQueryInformationActivationContext 00000000 0x11dee8 0x32d55c 3 0x12cfc8 1024 0x32d52c 0041:trace:module:find_dll_file found L"C:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef\comctl32.dll" for L"comctl32.dll" 0041:trace:ntdll:FILE_CreateFile handle=0x32d574 access=80100000 name=L"\??\C:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef\comctl32.dll" objattr=00000040 root=(nil) sec=(nil) io=0x32d578 alloc_size=(nil) attr=00000000 sharing=00000005 disp=1 options=00000060 ea=(nil).0x00000000 0041:trace:module:get_load_order looking for L"C:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef\comctl32.dll" 0041:trace:module:get_load_order got hardcoded default for L"C:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef\comctl32.dll" ... 0041:trace:module:load_dll L"C:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef\comctl32.dll" is a fake Wine dll 0041:trace:module:load_builtin_dll Trying built-in L"comctl32.dll" ... 0041:trace:module:load_builtin_callback loaded comctl32.dll 0x12b610 0x7dd70000 0041:trace:loaddll:load_builtin_dll Loaded L"C:\windows\system32\comctl32.dll" at 0x7dd70000: builtin ... 0041:Call comctl32.InitCommonControls() ret=00a9ee2a 0041:Ret comctl32.InitCommonControls() retval=7dd8d037 ret=00a9ee2a ... 0041:Call KERNEL32.GetModuleHandleW(04fdfb88 L"comctl32.dll") ret=008d758c 0041:Ret KERNEL32.GetModuleHandleW() retval=7dd70000 ret=008d758c ... 0041:Call comctl32.DllGetVersion(0032ef64) ret=00a9df26 0041:Ret comctl32.DllGetVersion() retval=00000000 ret=00a9df26 ... --- snip ---
Even if common control v6 activation context is there, the dll version check will still fail (WinSxS one has v5.81 version in resources)
Source:
https://source.winehq.org/git/wine.git/blob/79f93ecf429f42db15bc14f276045fda...
--- snip --- 108 #define WINE_FILEDESCRIPTION_STR "Wine Common Controls" 109 #define WINE_FILENAME_STR "comctl32.dll" 110 #define WINE_FILEVERSION COMCTL32_VERSION, COMCTL32_VERSION_MINOR, 4704, 1100 111 #define WINE_FILEVERSION_STR "5.81" 112 #define WINE_PRODUCTVERSION WINE_FILEVERSION 113 #define WINE_PRODUCTVERSION_STR WINE_FILEVERSION_STR --- snip ---
It seems newer wxWidgets dropped these questionable checks as part of larger cleanup:
https://trac.wxwidgets.org/ticket/17120
-> Pull request https://github.com/wxWidgets/wxWidgets/pull/82
https://github.com/wxWidgets/wxWidgets/pull/82/commits/03b243da21da917fe895c...
One can't force all the FOSS/commercial projects to upgrade their projects to use a newer wxWidgets version. Wine should provide reasonable compatibility, that is proper version resource for v6-based common controls.
$ sha1sum tlReader_10.1.0.2004.exe 0c09fb0d0d5efc89cb8ff5bc12ce15347e04a63e tlReader_10.1.0.2004.exe
$ du -sh tlReader_10.1.0.2004.exe 31M tlReader_10.1.0.2004.exe
$ wine --version wine-3.5
Regards
https://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #13 from Nikolay Sivov bunglehead@gmail.com --- I suppose it will work if we make DllGetVersion return v6 version conditionally, if it called with corresponding context.
I'm sure there will be a way to break it after that too, by checking version resource directly, or comparing module handles inside or outside of context.
http://bugs.winehq.org/show_bug.cgi?id=38987
--- Comment #14 from Nikolay Sivov bunglehead@gmail.com --- Wine now has a separate build of comctl32.dll that provides v6 version resource. This needs to be retested, if possible - I don't see mentioned application version available for download.
http://bugs.winehq.org/show_bug.cgi?id=38987
LingM lingm+winebz@posteo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lingm+winebz@posteo.org
--- Comment #15 from LingM lingm+winebz@posteo.org --- Version 10.1.0.2004 is still available here: https://tshwanedje.com/builds/2004/tlReader_10.1.0.2004.exe
Stable download link: https://web.archive.org/web/20251013233829/https://tshwanedje.com/builds/200...
Matches the sha1sum mentioned in the previous comments.
http://bugs.winehq.org/show_bug.cgi?id=38987
Andrew Nguyen arethusa26@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |541d9be5ecda1bc0c8fce22f131 | |8bf5d72572327 Resolution|--- |FIXED
--- Comment #16 from Andrew Nguyen arethusa26@gmail.com --- Trying to reproduce the +snoop analysis in comment 12, I could not directly confirm with +snoop traces that the comctl32 separation implemented in the latest master addressed the original issue in tlReader because the application crashes with +snoop enabled.
However, I see that with wine-10.16, when the Manx-English dictionary is loaded in the application, it renders the panes that are supposed to show word definitions completely white, and typing into a search box causes the following debug trace to be spammed:
0024:err:seh:dispatch_user_callback ignoring exception c0000005
After typing into a search box, the application also starts to continuously allocate memory until it exhausts its available address space.
With the latest master (wine-10.16-212-g6124fea1dde), the application properly shows word definitions, and typing into a search box no longer causes the dispatch_user_callback error trace to be printed nor does the application continuously allocate memory to exhaustion.
Reverse regression testing identified commit 541d9be5ecda1bc0c8fce22f1318bf5d72572327, which implements the final modifications for comctl32 separation, as the change that makes the application work properly, so I'm confident enough to resolve this bug as fixed.
I do see there is a regression in the rendering of the toolbar at the top of the application window that appears with the comctl32 separation, so I'll open a new bug for that.
http://bugs.winehq.org/show_bug.cgi?id=38987
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 10.17.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla