Closed master-bob closed 6 years ago
Thank you! That looks quite well.
I did a test build and checked my already installed windows/wine applications. I have to admit: They all run with wine64 instead of wine32 ... I was wrong with my years-old assumption that the image used 32bit architecture for wine. I am a bit confused because the image always provided 32bit-Gecko only without an issue.
For backwards compatibility, can you remove the line ENV WINEARCH win32
? Sorry.
~Please correct me if I am wrong, but my understanding is that Wine 1.8 is 32bit or at least only supports 32bit Windows. 64bit support of Windows applications was only added in Wine 2.~
Wine added 64bit support to Mac OS in 2.0.
And I see. I will make the change.
wine 1.8 in debian provides wine32 and wine64, so it supported both of them. On the other hand, all installation howtos insist on installing multiarch to avoid issues. I remember that I had issues if only wine64 was installed.
Furthermore, wine 1.8 accepted 32bit-gecko. wine 3.01 from wineHQ does not. But wine 3.01 from stretch-backports accepts 32bit-gecko, and adding 64bit-gecko to image would not be needed (just checked now). Maybe its the best for completeness to provide both gecko versions although only one is needed.
I admit, I am confused.
If I start my Windows applications previously installed with wine 1.8 with new wine 3.0.1, it complains that my ~/.wine
folder has a win64 prefix. Starting them with WINEARCH=win64
works.
Without setting ENV WINEARCH win32
wine 3.01 runs my old Windows applications. To provide backwards compatibility, its the best to leave the setting away.
While I was typing you provided a new commit. Thank you!
Much thanks for your contribution! It is a valuable improvement for the image.
Use stretch-backports to get the latest wine. Add 64bit Gecko. Ensure wine default environment is 32bit.
This would resolve the closed #3