1

While I am using wine to run some Windows exe program files on Lubuntu 18.04, I update and upgrade which probably have updated wine.

While I am still running the Windows exe programs, I try to run another Windows exe program,

$ wine another.exe
wine client error:0: version mismatch 547/571.
Your wineserver binary was not upgraded correctly,
or you have an older one somewhere in your PATH.
Or maybe the wrong wineserver is still running?

I don't want to exit the running Windows exe programs. Does that mean I shouldn't kill the running wine processes? What can I do to start the other window exe program?

Is this a common problem in deployment: rolling upgrade/deployment?

Thanks.

Improve this question
2
  • What have you done to address the error diagnostic? – roaima Dec 17 '19 at 23:36
  • cp -r ~/.wine ~/.wine-new, export WINEPREFIX=~/.wine-new and wine winecfg – Tim Dec 18 '19 at 15:26
1

I know it’s too late for that, but the general rule is that you shouldn’t upgrade Wine when it’s running, or if you do, plan on restarting the running instances as soon as possible after upgrading. (This is true of a number of other programs, such as Firefox and LibreOffice.)

I don't want to exit the running Windows exe programs. Does that mean I shouldn't kill the running wine processes?

Yes, you shouldn’t kill the running Wine processes.

What can I do to start the other window exe program?

You could copy your current Wine prefix to a new one, and start the upgraded Wine there — Wine runs one server per prefix. Assuming your current Wine prefix is ~/.wine, you would run

cp -a ~/.wine ~/.wine.new
WINEPREFIX=~/.wine.new wine /path/to/your/program.exe

Is this a common problem in deployment: rolling upgrade/deployment?

Yes, or at least, it’s a scenario which needs to be explicitly addressed: new versions of the server need to accept and handle connections from older versions of the client. In Wine’s case, clients expect to connect to a server running the same version; there is no provision for split upgrades. This expectation is embedded in a number of places: the main NTDLL checks the wineserver version, a number of DLLs check their corresponding Wine driver version, etc.

Improve this answer
7
  • Thanks. After copying prefix and renaming the copy directory, e.g. to ~/.wine-new, is what remains to do exactlyexport WINEPREFIX=~/.wine-new and wine winecfg? (wiki.winehq.org/…). In production of software engineering, how is rolling done broadly speaking? – Tim Dec 13 '19 at 11:46
  • I read quora.com/…. Rolling upgrade seems to apply only to client-server software. Upgrade server while client of older version is still running. Does this require multiple instances of server and move request to other instance? Does this require the server of new version be compatible with client of old version? (In case of Wine, that is not true?) Does client still need to be upgraded, but can be upgraded only after it voluntarily exit, or not necessarily since the server of new version can work with client of old version? – Tim Dec 13 '19 at 11:53
  • I think I get the idea. I will read more when I have time to. – Tim Dec 13 '19 at 11:58
  • By split upgrades, do you mean the software itself allows client and server with different versions to run together? Is that different from en.wikipedia.org/wiki/Rolling_release? – Tim Dec 14 '19 at 9:33
  • I’ve expanded my answer a little to address your prefix questions, and explain how software can handle rolling upgrades. Rolling upgrades are indeed only a problem when two pieces of software can be upgraded separately, but need to work together (and surprising though it may be, Wine is client-server software). Rolling releases are another matter entirely, releasing and upgrading are orthogonal concepts. – Stephen Kitt Dec 14 '19 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.