On 3/27/19 8:05 PM, Alexandre Julliard wrote:
Jacek Caban jacek@codeweavers.com writes:
Let me put Wine Gecko into design consideration again, mostly because it's simpler and I'd like to preserve that simplicity. Wine Gecko may be considered a just another library in a distro. The fact that it's a PE file is really just an implementation detail. From distro point of view, it may be treated just like any other .so library: just install it into the right place in a shared location. MSHTML would just find and try to use it. If it can be found, no MSI is involved at all. Otherwise the old way is used and installation is not shared. It's both simple and reliable.
FWIW, I'm currently working on a scheme to allow Wine builtin dlls to be built as PE files. Once this is in place, a package could simply drop PE dlls in /usr/lib/wine and they would be treated exactly the same as .so builtins. Maybe this could make things easier.
That sounds interesting. It would probably make things harder, but possibly nicer. There is a long standing bug about library name conflict (eg. nss3.dll from Wine Gecko may conflict with one shipped with application). If putting them in /usr/lib/wine would mean that whey are always visible to the application (like currently our builtins), the problem would escalate. Of course the right solution to that is to avoid conflicts. It's harder than it sounds, but it should be doable.
Also Wine Gecko contains some data files. They would probably need to go to /usr/share/wine or something. I will experiment with it when the time comes.
Thanks,
Jacek