Hi Vincent,
On 3/4/19 9:29 PM, Vincent Povirk wrote:
I'm considering implementing a system to allow the majority of Wine Mono to be kept in a shared location, rather than installed separately into each prefix. This is motivated by concerns expressed by Andrew about the amount of space it would take up on Proton, which creates a separate prefix for each game it runs. Currently, Proton doesn't include Wine Mono.
An empty Wine prefix on my current build takes up 686 MB. Most of this comes from addon directories that we could put anywhere. drive_c/windows/mono: 237.2 MB drive_c/windows/system32/gecko: 103.7 MB drive_c/windows/syswow64/gecko: 95.7 MB
The .msi installers for the addons are also copied into drive_c/windows/Installer, which takes another 186.6 MB. That means that 623.2 MB of the overhead of a Wine prefix is caused by Mono and Gecko. (For those who are curious how much of that can be blamed on me, personally, that number is 323.7 MB.)
It would be indeed nice to improve the situation. I'm happy to adopt Wine Gecko if we find a good solution (it could use maintenance release anyway, so the timing is right). Wine Gecko is easier, as you described. I'd expect a shared read only installation to work with unchanged Wine (although it'd need testing). User would just have to set GeckoPath registry in each prefix. That said, all we need it a code that would locate a global installation. Mono is more complicated, so we should concentrate on having that right first.
Design requirements:
- Wine must be able to download and verify Gecko and Mono packages if
they're not available. We currently accomplish this by downloading msi files from the Wine website and checking them against a hard-coded sha256 hash in Wine.
- Wine Mono contains some registry entries and files to make a fake
.NET installation. These files and registry entries must be packaged together so that it's possible to remove them when installing native .NET. MSI is very convenient for this, since it manages installs, upgrades, and removals.
- The files currently in windows/mono and windows/sys*/gecko must be
available once Windows code is running (unless the user chooses not to download them). They may be in a read-only location, and each prefix does not need a unique copy.
I am making the assumption that there's no need to write to the gecko folder once Wine Gecko is installed.
Proposal #1: Optional shared installs
If someone builds Wine from source and does nothing else, everything will work the same way it does now. Wine will download msi packages for Gecko and Mono, and install them.
Gecko and Mono will have a new option which installs directory trees to /usr/share/wine. This will include the current contents of windows/mono and windows/sys*/gecko. For Mono, it will also include an msi package which contains the remaining files and registry keys. The addons system will recognize if Gecko or Mono is installed there. If it finds them, it won't download an msi package. If it finds Mono, it will install the msi package from the shared location.
FWIW, the reason why Gecko wouldn't need an additional package is that those parts are in Wine itself. We have Wine-specific iexplore.exe -regserver (and -unregserver) that are used as an equivalent of uninstalling Mono MSI package. It's easy to do for registries; files may more tricky, but fake DLLs should be doable this way. Gecko way may be not suitable for Mono, but may be worth consideration. Do existing files prevent native .net installer from running or installing them? Are the files that you intend to install just fake DLLs? Could we have Wine install them itself?
We will provide builds of Gecko and Mono as an archive that can be extracted to /usr/share/wine, in addition to the current msi packages.
The mscoree and mshtml components will be updated to look for files in this shared location.
Proposal #2: CAB packages and shared installs
This is the same as proposal #1 for system-wide installs of Gecko or Mono.
For downloading and installing addons, we will use a .cab archive instead of .msi. The addon system will download and extract this to a user location but share those files between all of the user's prefixes. The cab contents will be the same as the files that would be installed into /usr/share/wine and will be used in the same way. The .msi packages will be discontinued.
This makes the different cases more consistent, but it may make it more difficult for users to install addon packages manually.
An important thing in past decisions was that prefixes should be transferable. For example, if you copy a prefix that uses a shared Mono to another machine that does not have Mono globally installed, it should still work. I guess now that have a reliable downloader/installer, we may just install required package the old way on the other machine. This can be done, but may need a special attention. Esp. if you'd implement the idea of "small" Mono MSI file, you'd need to make sure that it would not prevent complete install when shared location can not be located in runtime.
Another thing to consider is that shared Gecko/Mono installation may be not mappable to DOS drives (eg. removed z: drive). We could probably fallback to full "old way" in such case. Or maybe we could make it work with ??\unix paths, I'm not sure.
Jacek