RFC: reducing wasted disk space from addon files

Vincent Povirk vincent at codeweavers.com
Wed Mar 6 10:07:10 CST 2019


> If we stayed with MSI instead of CAB (probably we'd need both .msi for
> downloader and .tar.* file for shared install) then, we'd have two Mono
> MSIs. Let's call them big and small. I have limited knowledge about MSI,
> but it should be possible to have small MSI be both part of the big
> package and its dependency. With that, current appwiz.cpl should work
> out of the box - small MSI would be installed as part of big MSI.
> Then in mscoree, I imagine we'd need something among those lines:
>
> if (!find_mono_installation()) {
>
>      run_appwiz();
>
>      if (!find_mono_installation()) // fail
>
> }
>
> if (small_msi_not_installed()) install_small_msi();
>
> // consider Mono installed
>
>
> You could do that whenever you attempt to load mono and in
> DllRegisterServer to take care of updates. How does that sound?

That could work. It would solve the problem for packaged distributions
of Wine. If someone removes z:, or doesn't have wine-mono installed
globally, we would still have to download and install the msi. I'm
learning that solving those cases correctly is complex, so that might
be OK.

> It works because of Wine's \\?\unix paths. It uses
> MsiInstallProduct("\\\\?\\unix\\usr\\share\\wine\\gecko\\wine_gecko-2.47-x86.msi")
> in my case. Trying To use such paths as GeckoPath value fails, but I
> didn't look at details. We could probably make it work with enough
> efforts. Or we could just run full appwiz.cpl install in such case.

I wouldn't expect Windows code in general to respond well to that kind
of path. Maybe you can make this work for Gecko, but I'm not confident
it can work for Mono.



More information about the wine-devel mailing list