On 4/12/20 8:00 PM, Esme (they/them) wrote:
On Sun, Apr 12, 2020 at 6:27 PM Zebediah Figura z.figura12@gmail.com wrote:
(2) not prompting for every add-on (personally I feel that two is already too many),
Now that you mention it, I can't think of any reason we couldn't combine the prompts for the addons we have. We just need someone to do the work. The hard part is giving appwiz.cpl the ability to test for all addons including in shared locations, and chaining the steps together.
Well, I guess one reason is they're not all necessary. Of course, Wine has a default position of "ship everything" anyway, so maybe I should just bite the bullet and accept that...
I think some sort of manifest hack would be appropriate here, that ntdll would check when loading a builtin DLL. Presumably we don't even want the libraries to be copied into the prefix, but rather we want to make sure we load them always from /usr/i686-w64-mingw32/lib/* (or whatever the path is for any given distribution).
Maybe. The dependencies of those dependencies would also have to be loaded from system paths (builtin,distro,native search order?). We'd need the ability to use a list of paths for people who supply their own versions of the PE libraries, outside the paths controlled by the distribution. I'm not sure if we need to be concerned about how Windows programs will respond to seeing library dependencies resolved in a way that doesn't happen on Windows.
I still think an archive of PE dependencies has merit with this solution. You'd just have to extract it to /usr/local/, I guess.
I guess it's not obvious to me there's a difference between "builtin" and "distro" (though we'd presumably not go putting the Wine builtin flag in mingw libraries). But yeah, I guess we'd want to vary load order depending on whether the library is a dependency of a PE builtin or not, in some way.