RFC: reducing wasted disk space from addon files

Vincent Povirk vincent at codeweavers.com
Mon Mar 4 14:29:21 CST 2019


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.)

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.

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.



More information about the wine-devel mailing list