On 3/5/19 4:41 PM, Vincent Povirk wrote:
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.
I'm starting to favor the CAB approach for this reason.
We used CAB files in very early Wine Gecko days, the move to MSI was a nice change. It moved installation logic to the right place. In case of Gecko it's not really a big deal: one directory and one registry key, so I don't feel strongly about it.
For us to consider Wine Mono to be installed, we need the MSI and the Mono runtime. We could have logic which checks for both of these, and reruns the MSI if something is missing. That would take care of switching from a small MSI to the full one, but it makes checking for an install more complex. If we always have the Mono runtime installed in a shared addon location, we only need to check there. We can then run the MSI from the addon location unconditionally, and the MSI component will only do the install when it needs to.
This leaves the question of which component runs the MSI, and when. If mscoree does it, then appwiz.cpl only needs to manage static files, but doing the install via appwiz.cpl won't create a working installation. One would have to register mscoree or do a prefix update. If appwiz.cpl does it, that's some extra complexity that I'm not sure it should have.
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?
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.
How does this work currently? I would expect that an MSI can't install from outside the prefix in this configuration.
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.
Jacek