My wine programs used to work, but now they don't .
-
- Level 1
- Posts: 7
- Joined: Thu Mar 14, 2019 10:07 pm
My wine programs used to work, but now they don't .
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.
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.
Re: My wine programs used to work, but now they don't .
@nixlayzzer
You probably just need to manually update each WINEPREFIX, using:
(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
You probably just need to manually update each WINEPREFIX, using:
Code: Select all
wineboot -u
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
-
- Level 1
- Posts: 7
- Joined: Thu Mar 14, 2019 10:07 pm
Re: My wine programs used to work, but now they don't .
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.
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.
Re: My wine programs used to work, but now they don't .
This isn't a sustainable solution to your issues, IMHO.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.
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
...
Code: Select all
strace wine WINWORD.EXE &>~ wine_winword_log.txt
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/
Code: Select all
winetricks isolate_home
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
Bob
-
- Level 1
- Posts: 7
- Joined: Thu Mar 14, 2019 10:07 pm
Re: My wine programs used to work, but now they don't .
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:
PS: I got an error popup )
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)
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)
if I use that command with strace (Internal errors -invalid parameters received
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)
Re: My wine programs used to work, but now they don't .
@nixlayzzer
Using DLL override should always be a last resort, in any WINEPREFIX.
Just looking at:
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:
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):
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
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)
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
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
Bob