Wrye-bash: Wine hiccups

[Utumno]

Catch-all issue to verify WINE misfunctions and either solve them or open individual issues

• canVista
• double click on a mod:

Traceback (most recent call last): File "bash\basher\__init__.py", line 945, in OnDClick DocBrowser().Show() File "bash\basher\frames.py", line 97, in __init__ self, style=wx.NO_FULL_REPAINT_ON_RESIZE) File "C:\_Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\iewin.py", line 57, in __init__ id, pos, size, style, name) File "C:\_Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\activex.py", line 105, in __init__ self._ax = cc.GetBestInterface(unknown) File "C:\_Python27\lib\site-packages\comtypes\client\__init__.py", line 112, in GetBestInterface interface = getattr(mod, itf_name) AttributeError: 'module' object has no attribute 'IWebBrowser2'

• column sort indicators plain do not show

[Utumno]

@lojack5: canVista: https://github.com/wrye-bash/wrye-bash/blob/e93338e34e27355cc33326f4cf2d7f5eb1b2e244/Mopy/bash/balt.py#L681 is true in WINE no matter what - this breaks most of Bash 's dialogs (below is the too many mods one):

• can you explain to me what the vistaDialog does exactly ? What does it add ?
• any ideas how/if we can pass it its parameters so it works also in wine
• if no how about disabling it ? the windows py does not seem maintained anymore and I would be tempted to bin it - but I certainly need your opinion first

[lojack5]

vistaDialog: the new message dialog style in the Windows API that has tons of features. This page has a picture near the top showing one that happens to be utilizing nearly every feature of the API. It adds essentially much more flexibility in a Windows API dialog, rather than having to create custom dialogs for many many common cases, which is what was needed pre-Vista.

I'd assume that it's working on WINE because WINE is running/emulating a version of windows that's Vista+, so there shouldn't be an issue. I mean, the DLL is clearly exporting the API function, look at this, it's grabing the TaskDialogIndirect function exported by the comctl32.dll file. The picture you posted is unclear to me - is that an error that occurs when trying to launch Bash, or is that actually Bash showing a vista dialog, and it just happens to be really tiny?

For binning it - I'd avoid it if you can. Every version of windows past Vista still has the old message dialog APIs, but officially they're depricated and we should be using the TaskDialogIndirect or TaskDialog API functions to make dialog windows that don't need more complicated stuff.

That same page I linked first, provides a DLL for emulating the TaskDialogIndirect function on systems older than Windows Vista, for the case when you want the same styled dialogs even on older systems, but that's not what's needed here. I'd want to find out why the TaskDialog isn't (?) working in WINE, even though it clearly has the function in comctl32.dll. If you can't make it work at all, I'd try to find some way to detect if Bash is running under WINE, and if that's the case, just set canVista to False when that's detected.

For more info on the emulation DLL, you can check this commit, specifically the stuff at the bottom, for how you'd use that if you wanted to.

[lojack5]

Oh and a second though... under WINE you're still running Bash on 32-bit Python, yes? That same commit I linked fixed an issue with running under 64-bit Python related to TaskDialogIndirect, it was the _pack_ parameter I added to ensure the struct was the correct size under 64-bit.

[Utumno]

Thanks for the info - I may come for more :)

The picture you posted is unclear to me - is that an error that occurs when trying to launch Bash, or is that actually Bash showing a vista dialog, and it just happens to be really tiny?

Bash displays all dialogs that have a canVista True path this way - and I can't resize them

I'd want to find out why the TaskDialog isn't (?) working in WINE, even though it clearly has the function in comctl32.dll. If you can't make it work at all, I'd try to find some way to detect if Bash is running under WINE, and if that's the case, just set canVista to False when that's detected.

Yep - I am relatively linux n00b though so I don't really know if something on my setup - investigating

https://github.com/wrye-bash/wrye-bash/wiki/%5Bdev%5D-Running-Wrye-Bash-on-WINE-%28Arch-Linux%29

My wine python setup is 32:

$ wine /home/utumno/.wine/drive_c/_/Python27/python.exe 
Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> wx.version()
'2.8.12.1 (msw-unicode)'
>>>

Playing with wine options did not do any good - will keep investigating...

[Utumno]

@lojack5: Alright - rewrote the wiki article as now i have a clearer idea - i start suspecting that the lines:

fixme:commctrl:TaskDialogIndirect 0x2187470, 0x213a508, 0x213a558, 0x213a5a8
fixme:commctrl:TaskDialogIndirect dwCommonButtons=1 uType=0 ret=1

in the output point to a wine bug such as:

• https://www.winehq.org/pipermail/wine-bugs/2011-July/284149.html, ancient, fixed
• https://bugs.winehq.org/show_bug.cgi?id=34008#c2 - more recent, also fixed in 1.7.51 i use

So - any way we can change our side (call the TaskDialkog with other arguments) ?

Whatever I tried (including running from a wine 32 prefix) the only workaround is setting canVist=False manually (see the wiki)

[lojack5]

Bash uses only the most basic features of TaskDialog anyway, except for one case that I can think of. If you try to launch Bash and it detects that the game directory is UAC protected, the dialog it shows when asking to relaunch with admin rights uses a little prettier options.

Anyway, from that first link, and actually going through the diff that's linked there, it looks like the problem is that TaskDialogIndirect simply isn't fully implemented on wine:

with a partial implementation of TaskDialogIndirect from commit

[Utumno]

Yep I guessed so - I asked still waiting:

https://forum.winehq.org/viewtopic.php?f=8&t=25299&e=0&sid=3184e1736e37c2cfce91d2120e335c0f

• well no other way but to bug them - detecting if wine is there is not easy and a hack

[paolobolzoni]

As asked in https://github.com/wrye-bash/wrye-bash/issues/315 I report that the canVista setting still need to be explicitly put to False.

[Infernio]

User reported some more hiccups with tracebacks. Obviously somewhat low priority since we're finally getting closer to #243, but still:

1. When dragging and dropping to reorder mods/installers:

Traceback (most recent call last):
  File "bash\gui\list_ctrl.py", line 72, in OnData
    data = pickle.loads(self.dataList.GetData().tobytes())
AttributeError: 'NoneType' object has no attribute 'tobytes'

1. A few things cause this - more wx locale nonsense:

Traceback (most recent call last):
  File "C:\Oblivion\Mopy\bash\bash.py", line 203, in main
    _main(opts, wx_locale)
  File "C:\Oblivion\Mopy\bash\bash.py", line 366, in _main
    frame = app.Init() # Link.Frame is set here !
  File "bash\basher\__init__.py", line 4242, in Init
    frame = BashFrame() # Link.Frame global set here
  File "bash\basher\__init__.py", line 3871, in __init__
    self._native_widget.SetStatusBar(BashStatusBar(self._native_widget))
  File "bash\balt.py", line 2285, in __init__
    self.UpdateIconSizes()
  File "bash\basher\__init__.py", line 3751, in UpdateIconSizes
    self._addButton(link)
  File "bash\balt.py", line 2301, in _addButton
    gButton = link.GetBitmapButton(self)
  File "bash\basher\app_buttons.py", line 170, in GetBitmapButton
    window, self.images[idex].GetBitmap(), onRClick)
  File "bash\gui\base_components.py", line 452, in GetBitmap
    self.bitmap = _wx.Bitmap(self._img_path.s, self._img_type)
wxAssertionError: C++ assertion "wxString::Format("%.3f", 1.23).find(str) != wxString::npos" failed at ..\..\src\common\intl.cpp(1648) in wxLocale::GetInfo(): Decimal separator mismatch -- did you use setlocale()?If so, use wxLocale to change the locale instead.

wx4.1 might help here (https://github.com/wxWidgets/Phoenix/pull/1702), but obviously we're not going to move there yet.

[llde]

As Wine doesn't implement GMEM_MOVEABLE global memory used by wxWidgets, Wrye Bash will crash when drag and dropping esp files in the load order tab. (This beheviour is intreoduced by a regression in wine 4.8 that still exist today, with a Global Protpection Fault between wine 4.8 and 4.22, and a segfault after).

I updated the GMEM_MOVEABLE patchset in one of the wine bugs and posted here: https://github.com/Frogging-Family/community-patches/blob/master/wine-tkg-git/kernel32-implement-Windows-NT-style-GMEM_MOVEABLE-LM-staging.mypatch

@Infernio from my testing that bash\gui\list_ctrl.py is what happen on a wine 4.7 or previous install without the GMEM_MOVEABLE patchset. This is caused by the fact wxWidgets use HeapSize(GetCurrentProcess(),0, GlobalLockl(hGLobal)) instead of GlobalSize on global GMEM_MOVEABLE memory.
relevant wine bug: https://bugs.winehq.org/show_bug.cgi?id=38924

[afromanDAN]

Hello I'm having a wine crash trying to run the python source version. I have attached the wine traceback. IT seems that wxmsw314 is crashing it.
backtrace.txt

[Utumno]

Which Wrye Bash version / python versions?

[afromanDAN]

I am using wryebash 308 python source and python-2.7.18.amd64.

[Utumno]

Which wx python version?

[afromanDAN]

Looks like I am using wxpython-4.1.0.

On Fri, Mar 12, 2021 at 3:13 PM Utumno @.*> wrote:

Which wx python version?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/wrye-bash/wrye-bash/issues/240#issuecomment-797758752,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE5S3SJSVCEYYQHFWHJ253DTDJ7X5ANCNFSM4BQAQKFQ
.

[llde]

Hi, I'm tracking a strange bug that happen when using wine staging. Pratically the listview that shows a mod master files start completly black. When I click on a mod with masters, the master appear correctly (but the rest of the list is still black). Then if I click another mod with less master then the mod clicked before, the excess masters remain stuck.
This bug doesn't appean with non staging wine, and I bisected the problematic staging patchset:
Author: Dmitry Timoshkov [e-mail]
Date: Tue Nov 12 18:13:20 2019 +0800

comctl32: Bump version to 6.0.

An application that I have here checks comctl32.dll version information
and refuses to run, changing DLL version to 6.0 makes it run.

Now another strange thing is that I can consistently experience with the 309.1 standalone version, but not with the python source 309.1 version (installed prequisited using the provided requirements file). Some report on the Oblivion Community Server report at least 309 is affected, while 307 is not. (308 is untested)

[Utumno]

Thanks @llde - currently we are having a 310 experimental on discord featuring python 3 support! This is the version one should focus on - pre py3 versions will become ancient history once we switch to py3

Now another strange thing is that I can consistently experience with the 309.1 standalone version, but not with the python source 309.1 version (installed prerequisites using the provided requirements file)

Well this is another reason to ask people to use python - py2exe -> dll hell (see #491)