Designing for Multiple Wines
Sometimes one version of Wine can run an application, but fail on others. Maybe there’s a regression in the latest Wine version, or you’ve installed an optional patch that fixes one application but breaks another.
The solution to this is to have more than one version of Wine installed on the system, and have the system determine which version of Wine is best for the application. This implies two different levels of usability – advanced users may want to configure and tweak which Wine runs which App, but mere humans won’t even want to know such a thing exists.
This is the reason why many people have created Wine front ends: they worry about things like patches and registry hacks and native DLLs so that users won’t have to. You just click a button for the application you want to install, put in the requisite disc or password, and it does all the shaman dances for you. Codeweaver’s, the chief sponsor of Wine, stays in business through sales of Crossover, which is basically just a front end to a special version of Wine.
So, these front ends exist to solve some very real and important problems. But now we have a new problem, in that we might have more than one front end — playonlinux, winetricks, and others all need to deal with this too. In true open source fashion, we need to work together and come up with a standard.
My proposed solution:
Distribution packagers like me make a separate package, say, wine-hotfixes. This package replaces (on Ubuntu via dpkg-diversions) the /usr/bin/wine binary, moving the existing one to /usr/bin/wine-default.
The new /usr/bin/wine will pass everything to wine-default, unless it detects the environment variable WINEHOTFIXES is set to something other than null. If it is set (to, say WINEHOTFIXES=”6971,12234″), then the script will look in /etc/wine/hotfixes.d/ and /etc/wine/hotfixes.conf for alternative wine versions that might make it happy. In the case of a partial match it will prioritize bugs in the listed order.
hotfixes.d will contain a series of config files, one for each alternative version of wine. These could be installed manually, but generally they’ll come from special packages — say, a version of Wine built with a workaround for that annoying mouse escape bug. Each file will give a path (say, /opt/wine-hotfixes/yokos-tweaked-wine) and which bugs it hotfixes. hotfixes.conf can specify a list of bugs that the default Wine already fixes, as well as which bugs to ignore (eg that are probably fixed by every hotfix).
Start menu items (.desktop entries) can then work exactly as they do now, except they will have the WINEHOTFIXES environment variable set, generally as created by a front end. If the user has no alternative wine versions, or no wine-hotfixes package, nothing different will happen and everything will still use the wine-default. If the user upgrades Wine to a version that fixes all the worked around bugs, the default will be used again (forward-compatible) — all that’s needed is for the newer Wine package to ship an updated hotfixes.conf.
The beauty of this is that a front end can specify a list of bugs to workaround without actually having a ready hotfix – if needed that can be handled by someone else. Similarly, the hotfixed Wines don’t actually need to know about which app they’ll be running, as wine-hotfixes will do all the matchmaking. We also keep /usr/bin free, except for one added binary.
Wrapping it all up
The real test of a design, of course, is if it can be any simpler. With the above, we’ve got it down to a single configuration item depending on who’s using it — hotfixes.d for the packager, hotfixes.conf for a manual tweaker, and the WINEHOTFIXES environment variable for the front end author.
It is of course worth asking if we should be doing this at all. Zero configurations are better than one, after all, and ideally one magic Wine package would run every application flawlessly. But that’s what we’ve been trying for years now, and people keep feeling the need to write these front ends anyway — we’re clearly not doing well enough without them, so we might as well manage them and work together. This way, at least everything is backwards (and forwards) compatible: environment variables mean nothing without wine-hotfixes, and if we ever do invent a perfect version of Wine all the applications installed by front ends will continue to work just fine.
That should wrap it up, unless I’ve missed something.