Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

[James Mckenzie]

Alexandre Julliard  wrote:
> Sent: Feb 17, 2009 5:07 AM
> To: Dan Kegel 
> Cc: "[e-mail]" 
> Subject: Re: search path redux - if office 2007 always uses a private riched20,	why does wine interpose its own global one?
>
> Dan Kegel  writes:
> > See http://bugs.winehq.org/show_bug.cgi?id=14980
> >
> > Essentially, to run Office 2007, you have to set an override
> > for riched20.  Since Office installs a new, spiffier version
> > of riched20 in its own private directory, and expects to
> > find it there, isn't it a bug that we don't let it have it?
>
> There's no guarantee that using the private version would help. In some
> cases it does, in other cases it makes things worse. So defaulting to
> builtin is preferable, this way at least when it doesn't work we have a
> chance of fixing it.

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.  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.  However, this breaks when the system is upgraded (witness what happened to a bunch of programs when XP SP2 was released or you upgraded from Windows 3.1 to Windows 3.11, etc.).  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.  This allows the Wine project to call Wine specific versions of library code and continue to use program supplied dlls.  Good idea and one that should be retained.  However, some programs will NOT function without their program specific dlls, and it appears that Office 2007 is one of them.  Thus, it will be necessary to switch from built-in to native, built-in for this program until Wine incorporates all of the new functions.  This may also be true of other programs.

James McKenzie

search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

[Dan Kegel]

On Tue, Feb 17, 2009 at 6:23 AM, James Mckenzie
 wrote:
> However, some programs will NOT function without their program specific dlls, and it appears that Office 2007 is one of them.  Thus, it will be necessary to switch from built-in to native, built-in for this program until Wine incorporates all of the new functions.

But in this case, the app is using a private fork of the DLL in question,
and the new functions in the private fork will probably never go
into the public one.

search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

[Francois Gouget]

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).