RFC: reducing wasted disk space from addon files

[Jacek Caban]

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