On Tue, 17 Feb 2009, James Mckenzie wrote: [...]
I think the phrase for this is 'dll hell'. That is Application A ships with and places a copy of xyz.dll in the program directory and uses it, exclusively.
No. Dll hell is when Application A 'upgrades' (replaces) a system dll in c:\Windows\system32, thus breaking Application B. What you describe, putting customized dlls you need in your own c:\Program Files\Xxx directory is a reaction to dll hell and is supposed to avoid it.
This was fine for some versions of Windows when xyz.dll could add in its own functions at the end of the dll and include all of the functionality of the system provided xyz.dll.
Functions are not added at the start or end of dlls. They are just added.
This may or may not happen with Wine because we added the ability to first call the Native xyz.dll and if a function did not exist there, call Wine's xyz.dll.
As far as I know Wine does not automagically fall back to Wine's implementation if a function is missing from a native dll. You need to set the dll overrides manually. It's better than having to grab backed up dlls to copy them to the program's directory like you would have to do on Windows, but not very much (for non-technical users it's really the same).