winetricks & DLL overrides

Hi Dan,

i'm happy user of winetricks and thanks for all that work. Today i
found out, that i wasn't able to reveal, that apps uses some native
dll  when using:

winetricks settings alldlls=builtin

further checking revealed, that winetricks(20120308) has several no
longer available dll override compared to winecfg and some are
missing, thus application uses them as native.

So i add/del dlls from override_all_dlls list based on winecfg
(1.5.3-164-gdec3d50) and the result is attached as a patch.

Probably unusable for you, because:
* no care about line length

* i do not know whether removing no longer available dll's override
is allowed (what's happen for users using old wine-1.0 and need
dlls's override no longer available in wine-1.5.3)

* shouldn’t be the dll's override in user.reg simply overwritten? As
i noticed the names are there twice - 2nd one with "*" prefix making
it confusing, which value will be used and the list in winecfg is
twice as long.

Thanks and regards,
W.

[Dan Kegel]

On Sat, May 5, 2012 at 9:26 PM,   wrote:
> winetricks settings alldlls=builtin
>
> further checking revealed, that winetricks(20120308) has several no
> longer available dll override compared to winecfg and some are
> missing, thus application uses them as native.
>
> So i add/del dlls from override_all_dlls list based on winecfg
> (1.5.3-164-gdec3d50) and the result is attached as a patch.

I'm not sure keying off the list in winecfg is the right thing to do;
I'd rather use the list of all wine dlls.  (dbghelp, for instance, should
still be in the list, I think.)
> - i do not know whether removing no longer available dll's override
>
> is allowed (what's happen for users using old wine-1.0 and need
> dlls's override no longer available in wine-1.5.3)

winetricks alldlls=builtin is mostly a tool for people using bleeding
edge wine to help identify remaining holes in wine, so no need
to worry about older versions of wine.
> - shouldn’t be the dll's override in user.reg simply overwritten? As
>
> i noticed the names are there twice - 2nd one with "*" prefix making
> it confusing, which value will be used and the list in winecfg is
> twice as long.

The comment in winetricks says
        # Note: if you want to override even DLLs loaded with an absolute path,
        # you need to add an asterisk
so I think it needs to be there.  (Otherwise we'll miss bundled dlls.)
Winetricks doesn't add it both ways, though,
so I wonder how the version without the asterisk got there.
Starting from a clean wineprefix should keep you from having multiple
entries.  Does it?
That should be fine for the intended audience.

I've updated winetricks (r813) to add all missing dlls and
added a comment explaining how the list was generated.

Thanks,
Dan

Od: "Dan Kegel"
> I'm not sure keying off the list in winecfg is the
> right thing to do;
> I'd rather use the list of all wine dlls. 
> (dbghelp, for instance, should
> still be in the list, I think.)

Many thanks, i use that since the release. But i noticed that
winecfg is messed by "DLLs" like Makefile, some .a library etc. It
probably doesn't hurt anything. Maybe generate the DLL list based
only on folders (not folders + "root" files)?
> Starting from a clean wineprefix should keep you
> from having multiple
> entries.  Does it?
> That should be fine for the intended audience.

Yes. That double listed DLLs in winecfg (with asterix + without
asterix) come from manually setting the DLL in winecfg and after
that running winetricks setting all the dll to builtin. Unfortunatly
the non-asterix verision wins, because the entries are latter in the
list. So winetricks may not do what one could except (all builtin).
I'm aware of that now, so again it doesn't hurt me.
> I've updated winetricks (r813) to add all missing dlls and

Thanks again for that.
W.