My wine programs used to work, but now they don't .

Questions about Wine on Linux
Locked
nixlayzzer
Level 1
Level 1
Posts: 7
Joined: Thu Mar 14, 2019 10:07 pm

My wine programs used to work, but now they don't .

Post by nixlayzzer »

About 5 years ago I created wine prefix folders and installed different Windows programs into them( one for Office, one for winRAR and so on). At that time it was wine version about 1.7. Some of them were installed by winetricks, some were by manual. They worked well and I kept them.

Last year I was still using those prefixes (my Linux distro and wine upgraded many times. I believe winetricks script also changed). It was about wine 2.x or 3.0 last year.

Today my Linux distro has wine 3.7. I try to use those prefixes, but now they have same issue (which didn't occur last year). Any program's open/save dialog crashes the program. Even notepad also. Then I downloaded wine's older stable(3.0.5) or latest(4.x) binaries to use on those prefixes, but unluckily same issue.

I tried creating new wine prefix with the current wine version, and run notepad. The dialog works fine.

So, my questions are:
I.
If I make a wine prefix folder and installed program, and find it works very well, can I keep it for many years and it will always work? For it do I need to keep using a standalone wine binary, not distro's, so wine version won't be upgraded, to keep it working? (My Linux distro needs to upgrade every year. I'm not sure if other libraries which are not a part of wine have impact on that. )
II.
Or, can I fix those prefixes? Cause reinstalling them costs a lot of work and time.
1. After winetricks code changed, can I fix program installed by winetricks?
2. For a wine prefix created by old version wine, do these operations really update it correctly? :
1) running new wine with old prefix to let wine automatically update prefix.
2) winecfg to change Windows version.
3) winecfg to tweak dlls.
User avatar
Bob Wya
Level 12
Level 12
Posts: 3068
Joined: Sat Oct 16, 2010 7:40 pm

Re: My wine programs used to work, but now they don't .

Post by Bob Wya »

@nixlayzzer

You probably just need to manually update each WINEPREFIX, using:

Code: Select all

wineboot -u
(which can of course be scripted easily enough...)

FYI
It's recommended to use the development version of Wine, currently 4,4
Basically because you won't get much support with earlier Wine versions (unless you can demonstrate that a regression has been introduced).
Bug fixes have to land in the development branch and they are very unlikely to be backported (to Wine stable).

Bob
nixlayzzer
Level 1
Level 1
Posts: 7
Joined: Thu Mar 14, 2019 10:07 pm

Re: My wine programs used to work, but now they don't .

Post by nixlayzzer »

Hi Bob, thanks for replying.

Is "wineboot -u" different from wine automatically updating prefix?
I just did "wineboot -u". That didn't make the open/save dialog work.

I downloaded old old stable wine 2.0.5 from POL. It works with my old prefixes. I think I'll stick 2.0.5 with my old prefixes. Unless somebody tell me how to make a 5-year-old prefix work with nowadays wine.
User avatar
Bob Wya
Level 12
Level 12
Posts: 3068
Joined: Sat Oct 16, 2010 7:40 pm

Re: My wine programs used to work, but now they don't .

Post by Bob Wya »

nixlayzzer wrote: ...
I downloaded old old stable wine 2.0.5 from POL. It works with my old prefixes. I think I'll stick 2.0.5 with my old prefixes. Unless somebody tell me how to make a 5-year-old prefix work with nowadays wine.
This isn't a sustainable solution to your issues, IMHO.

It would be useful to get some terminal output from Wine version 2.0.5 to compare this with the current Wine 4.4 release.
See: WineHQ FAQ: 10.1.1 How can I get a debugging log (a.k.a. terminal output)?
Please choose the simplest Windows program, or utility, that isn't working for you...

Please use the forum Code tags to delimit your full Wine command and terminal output:

Code: Select all

...
Please install and prefix your Wine command with strace, e.g.:

Code: Select all

strace wine WINWORD.EXE &>~ wine_winword_log.txt
so we can see what path(es) the Windows application is trying to access...
Probably something like WinRAR, would be the simplest to troubleshoot.


Have you left the symbolic links, to your Linux user's HOME directory, in each WINEPREFIX.
E.g. something like:

Code: Select all

llrwxrwxrwx 1 robert users   27 Mar 15 22:11 Desktop -> /home/robert/Desktop/
lrwxrwxrwx 1 robert users   32 Mar 15 22:11 My Documents -> /home/robert/My Documents/
lrwxrwxrwx 1 robert users   41 Mar 15 22:11 My Music -> /home/robert/My Documents/My Music/
lrwxrwxrwx 1 robert users   44 Mar 15 22:11 My Pictures -> /home/robert/My Documents/My Pictures/
lrwxrwxrwx 1 robert users   42 Mar 15 22:11 My Videos -> /home/robert/My Documents/My Videos/
This could also cause issues. I tend to remove these links, with:

Code: Select all

winetricks isolate_home
to avoid cruft in HOME directory and keep my WINEPREFIX's self-contained.


Also Wine doesn't just "automatically" update a WINEPREFIX...
That's why it can be useful to force this process with:

Code: Select all

wineboot -u
Thanks
Bob
nixlayzzer
Level 1
Level 1
Posts: 7
Joined: Thu Mar 14, 2019 10:07 pm

Re: My wine programs used to work, but now they don't .

Post by nixlayzzer »

Thank you Bob for those tips.

I think I managed to "fix" my old prefixes. My old prefixes had "comctl32(native, buildin)" in winecfg->libraries. I deleted it and then they work with wine 3.7. I didn't use "wineboot -u".

This is the original error when I click file->open in notepad.exe:

Code: Select all

$ wine notepad
0009:err:module:DelayLoadFailureHook failed to delay load comctl32.dll.HIMAGELIST_QueryInterface
wine: Call from 0x7b43f1bc to unimplemented function comctl32.dll.HIMAGELIST_QueryInterface, aborting
wine: Unimplemented function comctl32.dll.HIMAGELIST_QueryInterface called at address 0x770023:0x7b43f1bc (thread 0009), starting debugger...
Usage:
	winedbg [ [ --gdb ] [ <prog-name> [ <prog-args> ] | <num> | <file.mdmp> | --help ]

(exit code 84)
PS: I got an error popup
Internal errors -invalid parameters received
if I use that command with strace (

Code: Select all

strace wine notepad > dialog_error_stace.txt 2>&1
)


Still I'd like to know what's going on. Why the "comctl32(native, buildin)" worked on old wine 2.0.5 but not on newer wine? Will that happend to some other dlls?
I tried creating new prefix with wine 2.0.5 and set "comctl32(native, buildin)". Then I used wine 3.7 to run notepad.exe and click file->open. No problem happended. That's really strange.

(If you need more debug log or my prefix folder, I am willing to upload it)
User avatar
Bob Wya
Level 12
Level 12
Posts: 3068
Joined: Sat Oct 16, 2010 7:40 pm

Re: My wine programs used to work, but now they don't .

Post by Bob Wya »

@nixlayzzer

Using DLL override should always be a last resort, in any WINEPREFIX.

Just looking at:

Code: Select all

git diff wine-2.0.5 wine-4.4 dlls/comctl32/comctl32.spec

diff --git a/dlls/comctl32/comctl32.spec b/dlls/comctl32/comctl32.spec
index 1a5ab577932..34d9e7650d3 100644
--- a/dlls/comctl32/comctl32.spec
+++ b/dlls/comctl32/comctl32.spec
@@ -5,13 +5,13 @@
 
   2 stdcall MenuHelp(long long long long long long ptr)
   3 stdcall ShowHideMenuCtl(long long ptr)
-  4 stdcall GetEffectiveClientRect(long long long)
+  4 stdcall GetEffectiveClientRect(long ptr ptr)
   5 stdcall DrawStatusTextA(long ptr str long)
   6 stdcall CreateStatusWindowA(long str long long)
   7 stdcall CreateToolbar(long long long long long long ptr long)
   8 stdcall CreateMappedBitmap(long long long ptr long)
-  9 stdcall -noname DPA_LoadStream(ptr ptr ptr long)
- 10 stdcall -noname DPA_SaveStream(ptr ptr ptr long)
+  9 stdcall -noname DPA_LoadStream(ptr ptr ptr ptr)
+ 10 stdcall -noname DPA_SaveStream(ptr ptr ptr ptr)
  11 stdcall -noname DPA_Merge(ptr ptr long ptr ptr long)
 #12 stub Cctl1632_ThunkData32
  13 stdcall MakeDragList(long)
@@ -40,10 +40,10 @@
 236 stdcall -noname Str_SetPtrW(wstr wstr)
 320 stdcall -ordinal DSA_Create(long long)
 321 stdcall -ordinal DSA_Destroy(ptr)
-322 stdcall -ordinal DSA_GetItem(ptr long long)
+322 stdcall -ordinal DSA_GetItem(ptr long ptr)
 323 stdcall -ordinal DSA_GetItemPtr(ptr long)
-324 stdcall -ordinal DSA_InsertItem(ptr long long)
-325 stdcall -ordinal DSA_SetItem (ptr long long)
+324 stdcall -ordinal DSA_InsertItem(ptr long ptr)
+325 stdcall -ordinal DSA_SetItem (ptr long ptr)
 326 stdcall -ordinal DSA_DeleteItem(ptr long)
 327 stdcall -ordinal DSA_DeleteAllItems(ptr)
 328 stdcall -ordinal DPA_Create(long)
@@ -61,8 +61,9 @@
 340 stdcall -ordinal DPA_CreateEx(long long)
 341 stdcall -noname SendNotify(long long long ptr)
 342 stdcall -noname SendNotifyEx(long long long ptr long)
+344 stdcall -ordinal TaskDialog(long long wstr wstr wstr long wstr ptr)
 345 stdcall -ordinal TaskDialogIndirect(ptr ptr ptr ptr)
-350 stdcall -noname -private StrChrA(str str)
+350 stdcall -noname -private StrChrA(str long)
 351 stdcall -noname -private StrRChrA(str str long)
 352 stdcall -noname -private StrCmpNA(str str long)
 353 stdcall -noname -private StrCmpNIA(str str long)
@@ -93,10 +94,10 @@
 382 stdcall -noname SmoothScrollWindow(ptr)
 383 stub -noname DoReaderMode
 384 stdcall -noname SetPathWordBreakProc(ptr long)
-385 stdcall -ordinal DPA_EnumCallback(long long long)
-386 stdcall -ordinal DPA_DestroyCallback(ptr ptr long)
-387 stdcall -ordinal DSA_EnumCallback(ptr ptr long)
-388 stdcall -ordinal DSA_DestroyCallback(ptr ptr long)
+385 stdcall -ordinal DPA_EnumCallback(ptr ptr ptr)
+386 stdcall -ordinal DPA_DestroyCallback(ptr ptr ptr)
+387 stdcall -ordinal DSA_EnumCallback(ptr ptr ptr)
+388 stdcall -ordinal DSA_DestroyCallback(ptr ptr ptr)
 389 stub -noname SHGetProcessDword
 390 stdcall -noname ImageList_SetColorTable(ptr long long ptr)
 400 stdcall -ordinal CreateMRUListW(ptr)
@@ -193,5 +194,6 @@
 @ stdcall PropertySheet(ptr) PropertySheetA
 @ stdcall PropertySheetA(ptr)
 @ stdcall PropertySheetW(ptr)
+@ stdcall RegisterClassNameW(wstr)
 @ stdcall UninitializeFlatSB(long)
 @ stdcall _TrackMouseEvent(ptr)
shows that there was a few API call specification changes between Wine 2.0.5 and Wine 4.4 , in Wine's implementation of the comctl32.dll

When using native -> builtin Wine will try the native implementation for any API call (from that library), then fallback to Wine's builtin version.
This switching process can cause issues.

You would have had to install the native Windows comctl32.dll , e.g. using winetricks:

Code: Select all

winetricks comctl32
for the override to have any actual affect. Otherwise it will be ignored (as the native Windows binary won't be present in the WINEPREFIX).

You can see what libraries are being loaded, and whether these are native or builtin libraries, by running (as an example):

Code: Select all

export WINEDEBUG=+loaddll
wine notepad.exe
Which is often a useful debugging test... E.g. detecting when a game tries to load a d3dcompiler library, which is not fully supported under Wine.

Bob
Locked