search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
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?
Sounds like it's time to write a conformance test... sure would be nice if that override wasn't needed.
Dan Kegel dank@kegel.com 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.
2009/2/17 Alexandre Julliard julliard@winehq.org
Dan Kegel dank@kegel.com 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.
Well, no, that's the nature of dlls though. There's no guarantee that if an app supplies one to override a system dll it will make anything run any "better" than the system dll.
However the app that supplies a dll most certainly expects it will get that dll, including whatever buggy behaviour it contains and may indeed rely on to work, which is why Windows lets the app hang itself with its own rope and looks there first.
-- Chris
On Tue, Feb 17, 2009 at 6:07 AM, Alexandre Julliard julliard@winehq.org wrote:
Dan Kegel dank@kegel.com 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.
-- Alexandre Julliard julliard@winehq.org
What happened to 'bug for bug compatibility'?
On Tue, Feb 17, 2009 at 4:07 AM, Alexandre Julliard julliard@winehq.org wrote:
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.
OK, but that leaves Office 2007 broken for the average user, which can't be good. A whitelist of apps for which specific private DLLs are needed would solve this particular case. That's a hack, and against winehq policy, but because of the overwhelming popularity of the app, it's probably worth it for us to hold our noses and do that. No? - Dan
Dan Kegel dank@kegel.com writes:
OK, but that leaves Office 2007 broken for the average user, which can't be good. A whitelist of apps for which specific private DLLs are needed would solve this particular case. That's a hack, and against winehq policy, but because of the overwhelming popularity of the app, it's probably worth it for us to hold our noses and do that. No?
No. Find a better way.
For instance, investigate the possibility of checking version resources.
On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard julliard@winehq.org wrote:
No. Find a better way.
For instance, investigate the possibility of checking version resources.
Which version resources are you thinking of?
Dan Kegel dank@kegel.com writes:
On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard julliard@winehq.org wrote:
No. Find a better way.
For instance, investigate the possibility of checking version resources.
Which version resources are you thinking of?
The version of the native dll, compared to the builtin. I could imagine a heuristic where if the major version of native is higher than builtin you default to native or something like that. I'm sure there are other possibilities too.
On Tue, Feb 17, 2009 at 7:10 AM, Alexandre Julliard julliard@winehq.org wrote:
Which version resources are you thinking of?
The version of the native dll, compared to the builtin. I could imagine a heuristic where if the major version of native is higher than builtin you default to native or something like that. I'm sure there are other possibilities too.
Oh. Thanks for the hint! - Dan
On Tue, Feb 17, 2009 at 7:10 AM, Alexandre Julliard julliard@winehq.org wrote:
The version of the native dll, compared to the builtin. I could imagine a heuristic where if the major version of native is higher than builtin you default to native or something like that.
I've updated http://bugs.winehq.org/show_bug.cgi?id=14980 with that hint.
Say, have we considered making riched20 prefer native? That makes the app work, too. - Dan
--- a/dlls/riched20/editor.c +++ b/dlls/riched20/editor.c @@ -2743,6 +2743,9 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved TRACE("\n"); switch (fdwReason) { + case DLL_WINE_PREATTACH: + return FALSE; /* prefer native version */ +
On Fri, Feb 27, 2009 at 3:14 PM, Dan Kegel dank@kegel.com wrote:
Say, have we considered making riched20 prefer native? That makes the app work, too.
A couple of things to note, in case they are relevant: 1. msftedit currently uses the native version by default 2. builtin msftedit will not work with native riched20, since the classes native msftedit loads are instead loaded by builtin riched20, and msftedit just loads riched20
On Fri, Feb 27, 2009 at 3:02 PM, Dylan Smith dylan.ah.smith@gmail.com wrote:
Say, have we considered making riched20 prefer native? That makes the app work, too.
A couple of things to note, in case they are relevant:
- msftedit currently uses the native version by default
- builtin msftedit will not work with native riched20, since the classes
native msftedit loads are instead loaded by builtin riched20, and msftedit just loads riched20
Hmm. So making riched20 prefer native would break apps that use msftedit, if native riched20 but no native msftedit is present?
Does this mean that our msftedit is doing things differently than the native one? - Dan
On Fri, Feb 27, 2009 at 8:32 PM, Dan Kegel dank@kegel.com wrote:
Hmm. So making riched20 prefer native would break apps that use msftedit, if native riched20 but no native msftedit is present?
Yes. Although I haven't heard of this being an issue with people using winetricks.
Does this mean that our msftedit is doing things differently than the native one?
Yes, native is like a newer version of riched20, not a wrapper like builtin msftedit. Of course this may change, since riched32 used to be a complete implementation, but was later turned into a wrapper around riched20.
In order to do this the same way as native msftedit we would probably need to recompile the riched20 code using a version macro to select different behaviour for different parts of the code. This is seperate from 1.0 emulation which msftedit also allows, despite it's actually inconsistency with riched32 on it's improvements to riched20 (e.g. improvement in table implementation). However, distinguishing between different version didn't seem popular when I proposed the idea before, so I am waiting until this inconsistency actually causes problems for any applications.
Either way, I don't think it would be much worse than the way things are for both dlls to prefer native. I am not opposed to any of the ideas proposed for fixing the bug (whether it is checking if it is loaded from the system32 directory, using a heuristic based on version of the dll, or having riched20 prefer native). What matters is what Julliard prefers, so I am just trying to provide any relevant knowledge.
I think we never pursued the question Dan posed in this subject line.
That is, Powerpoint 2007 makes the following call: Call KERNEL32.LoadLibraryA(0033c0a8 "C:\Program Files\Common Files\Microsoft Shared\office12\riched20.dll")
It's clearly trying to load it's private dll. Instead of loading that private copy, we load the builtin riched20 instead. The builtin isn't 'good enough', and Powerpoint fails. Isn't that wrong? Shouldn't we prefer an explicitly referenced native dll to a builtin, even in builtin,native load order?
The attached proof of concept patch allows Powerpoint to display the troubled presentation.
If I am on the right track, does it make sense to add a conformance test to create a bare bones %TEMP%\riched20.dll and load it?
Cheers,
Jeremy
diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c index 71d7ecd..ef66b50 100644 --- a/dlls/ntdll/loader.c +++ b/dlls/ntdll/loader.c @@ -1977,6 +1977,9 @@ static NTSTATUS load_dll( LPCWSTR load_path, LPCWSTR libname, DWORD flags, WINE_ case LO_DEFAULT: /* default is builtin,native */ nts = load_builtin_dll( load_path, filename, handle, flags, pwm ); if (!handle) break; /* nothing else we can try */ + /* file is not a builtin library, if we we have a real file, try native */ + if (nts == STATUS_INVALID_IMAGE_FORMAT && handle && loadorder != LO_BUILTIN) + nts = load_native_dll( load_path, filename, handle, flags, pwm ); /* file is not a builtin library, try without using the specified file */ if (nts != STATUS_SUCCESS) nts = load_builtin_dll( load_path, filename, 0, flags, pwm );
I think your approach is peachy, but Alexandre wanted a version check; look at his most recent post in this thread:
... The version of the native dll, compared to the builtin. I could imagine a heuristic where if the major version of native is higher than builtin you default to native or something like that. I'm sure there are other possibilities too.
On Fri, Oct 16, 2009 at 8:10 PM, Jeremy White jwhite@codeweavers.com wrote:
I think we never pursued the question Dan posed in this subject line.
That is, Powerpoint 2007 makes the following call: Call KERNEL32.LoadLibraryA(0033c0a8 "C:\Program Files\Common Files\Microsoft Shared\office12\riched20.dll")
It's clearly trying to load it's private dll. Instead of loading that private copy, we load the builtin riched20 instead. The builtin isn't 'good enough', and Powerpoint fails. Isn't that wrong? Shouldn't we prefer an explicitly referenced native dll to a builtin, even in builtin,native load order?
The attached proof of concept patch allows Powerpoint to display the troubled presentation.
If I am on the right track, does it make sense to add a conformance test to create a bare bones %TEMP%\riched20.dll and load it?
Cheers,
Jeremy
diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c index 71d7ecd..ef66b50 100644 --- a/dlls/ntdll/loader.c +++ b/dlls/ntdll/loader.c @@ -1977,6 +1977,9 @@ static NTSTATUS load_dll( LPCWSTR load_path, LPCWSTR libname, DWORD flags, WINE_ case LO_DEFAULT: /* default is builtin,native */ nts = load_builtin_dll( load_path, filename, handle, flags, pwm ); if (!handle) break; /* nothing else we can try */
- /* file is not a builtin library, if we we have a real file, try
native */
- if (nts == STATUS_INVALID_IMAGE_FORMAT && handle && loadorder !=
LO_BUILTIN)
- nts = load_native_dll( load_path, filename, handle, flags, pwm
); /* file is not a builtin library, try without using the specified file */ if (nts != STATUS_SUCCESS) nts = load_builtin_dll( load_path, filename, 0, flags, pwm );
Dan Kegel wrote:
I think your approach is peachy, but Alexandre wanted a version check; look at his most recent post in this thread:
Alexandre wanted a version check when asked a different question. That question was when would we prefer an available native Richedit over the builtin one. (i.e. in the LoadLibrary("riched20") case).
I think if we get a loadlibrary on an explicit private path, we should load that dll natively, even if we have a builtin dll of the same name.
Cheers,
Jeremy
On Sat, Oct 17, 2009 at 6:31 AM, Jeremy White jwhite@codeweavers.com wrote:
Alexandre wanted a version check when asked a different question. That question was when would we prefer an available native Richedit over the builtin one. (i.e. in the LoadLibrary("riched20") case).
Looking back at the bug, that one uses an absolute path, too: 00e6:Call KERNEL32.LoadLibraryA(0032a40c "C:\Program Files\Common Files\Microsoft Shared\office12\riched20.dll") ret=3261c0d6
I think if we get a loadlibrary on an explicit private path, we should load that dll natively, even if we have a builtin dll of the same name.
Totally. - Dan
On Sat, Oct 17, 2009 at 5:22 PM, Dan Kegel dank@kegel.com wrote:
On Sat, Oct 17, 2009 at 6:31 AM, Jeremy White jwhite@codeweavers.com wrote:
Alexandre wanted a version check when asked a different question. That question was when would we prefer an available native Richedit over the builtin one. (i.e. in the LoadLibrary("riched20") case).
Looking back at the bug, that one uses an absolute path, too: 00e6:Call KERNEL32.LoadLibraryA(0032a40c "C:\Program Files\Common Files\Microsoft Shared\office12\riched20.dll") ret=3261c0d6
I think if we get a loadlibrary on an explicit private path, we should load that dll natively, even if we have a builtin dll of the same name.
I guess loading the native dll when an absolute path is specified is correct. It might also be useful to figure our where the LoadLibrary is really coming from as it might be a bug in a different part of Wine. Assuming Microsoft correctly uses technologies like manifest to fix version hell, I can imagine that Office 2007 is using this for loading riched20.dll and assuming that is the case the LoadLibrary is coming from Wine itself and it would mean that some of our activation context is not working correctlly.
Roderick
Jeremy White jwhite@codeweavers.com writes:
Dan Kegel wrote:
I think your approach is peachy, but Alexandre wanted a version check; look at his most recent post in this thread:
Alexandre wanted a version check when asked a different question. That question was when would we prefer an available native Richedit over the builtin one. (i.e. in the LoadLibrary("riched20") case).
I think if we get a loadlibrary on an explicit private path, we should load that dll natively, even if we have a builtin dll of the same name.
No, you don't want that. There are cases of apps shipping with their own copy of system dlls, and using native in that case is wrong. It's only for apps having a non-standard version of a system dll that we may want to use native. In general we should always err on the side of using builtin.
On Sat, Oct 17, 2009 at 9:35 AM, Alexandre Julliard julliard@winehq.org wrote:
I think if we get a loadlibrary on an explicit private path, we should load that dll natively, even if we have a builtin dll of the same name.
No, you don't want that. There are cases of apps shipping with their own copy of system dlls, and using native in that case is wrong. It's only for apps having a non-standard version of a system dll that we may want to use native. In general we should always err on the side of using builtin.
OK, so even on an absolute path, we need to do a version check, and only use the bundled copy if it's newer than builtin? (That's what I thought you meant earlier.)
Dan Kegel dank@kegel.com writes:
OK, so even on an absolute path, we need to do a version check, and only use the bundled copy if it's newer than builtin? (That's what I thought you meant earlier.)
Yes, and even that may not be enough, it may have to be limited further to some very specific cases.
Alexandre Julliard wrote:
Dan Kegel dank@kegel.com writes:
OK, so even on an absolute path, we need to do a version check, and only use the bundled copy if it's newer than builtin? (That's what I thought you meant earlier.)
Yes, and even that may not be enough, it may have to be limited further to some very specific cases.
How do we go about identifying those specific cases? Should we start with a list of dlls (with one entry in the list - riched20)?
Cheers,
Jeremy
Jeremy White jwhite@codeweavers.com writes:
Alexandre Julliard wrote:
Yes, and even that may not be enough, it may have to be limited further to some very specific cases.
How do we go about identifying those specific cases? Should we start with a list of dlls (with one entry in the list - riched20)?
Only as a last recourse. We can most likely find better ways of addressing that specific problem, for example by having riched20 itself take care of it instead of doing it in the loader.
Dan Kegel wrote:
On Fri, Feb 27, 2009 at 3:02 PM, Dylan Smith dylan.ah.smith@gmail.com wrote:
Say, have we considered making riched20 prefer native? That makes the app work, too.
A couple of things to note, in case they are relevant:
- msftedit currently uses the native version by default
- builtin msftedit will not work with native riched20, since the classes
native msftedit loads are instead loaded by builtin riched20, and msftedit just loads riched20
Hmm. So making riched20 prefer native would break apps that use msftedit, if native riched20 but no native msftedit is present?
Does this mean that our msftedit is doing things differently than the native one?
Let's stick a fork in this conversation for a moment and think about what we are saying here:
Office 2007 comes with an 'improved' richedit handing set of files, riched20.dll and riched32.dll which function drastically different from those supplied with WindowsXP and even possibly Vista.
So what do we do?
1. Detect and use the native dlls for Office2007 and use ours for everything else (or) 2. Work on blackboxing those dlls and adding in those functions that are not currenly supported into the native dlls?
I prefer the second solution as this gets rid of 'dll hell' and makes our dlls implementations better than those of MicroSoft.
Opinions from those gathered around the soapbox?
James McKenzie
On Sat, Oct 17, 2009 at 12:12 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
Let's stick a fork in this conversation for a moment and think about what we are saying here:
Office 2007 comes with an 'improved' richedit handing set of files, riched20.dll and riched32.dll which function drastically different from those supplied with WindowsXP and even possibly Vista.
So what do we do?
- Detect and use the native dlls for Office2007 and use ours for
everything else (or) 2. Work on blackboxing those dlls and adding in those functions that are not currenly supported into the native dlls?
I think the Office-supplied versions of riched20 and maybe gdiplus are 'special' forks that are never going to be released for other apps to use. It probably makes some sense to just use them rather than reimplement them.
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.
If you don't mind hearing from a real user...
I have both Office 2003 (which also installs the private dlls) and Office 2007 on my system. I regularly use Word, occasionally Powerpoint, and I can verify that it solves a number of other bugs besides the one Dan pointed to:
http://bugs.winehq.org/show_bug.cgi?id=15269 http://bugs.winehq.org/show_bug.cgi?id=14041 http://bugs.winehq.org/show_bug.cgi?id=8358
Now, as for the risk of making things worse: with Word 2003, I did originally encounter one minor glitch caused by the override (needed for the thesaurus): it used to trigger a popup error message about a file not found when using Insert=>Special Characters. It did not stop the feature from working (you could simply close the popup), and is no longer happening in recent versions of Wine, but it does raise the question of whether bugs triggered by using the private dll would be considered valid.
Finally, the issue goes beyond riched20--Office 200x installs other private dlls. An override for usp10 is needed to get the equation toolbar working in Word 2007.
On Tue, Feb 17, 2009 at 8:10 AM, Rosanne DiMesio dimesio@earthlink.net wrote:
I have both Office 2003 (which also installs the private dlls) and Office 2007 on my system. I regularly use Word, occasionally Powerpoint, and I can verify that it solves a number of other bugs besides the one Dan pointed to:
http://bugs.winehq.org/show_bug.cgi?id=15269 http://bugs.winehq.org/show_bug.cgi?id=14041 http://bugs.winehq.org/show_bug.cgi?id=8358
Now, as for the risk of making things worse: with Word 2003, I did originally encounter one minor glitch caused by the override (needed for the thesaurus): it used to trigger a popup error message about a file not found when using Insert=>Special Characters. It did not stop the feature from working (you could simply close the popup), and is no longer happening in recent versions of Wine, but it does raise the question of whether bugs triggered by using the private dll would be considered valid.
Finally, the issue goes beyond riched20--Office 200x installs other private dlls. An override for usp10 is needed to get the equation toolbar working in Word 2007.
That's good data, thanks. Now whoever implements Alexandre's suggestion has more to test against. - Dan
-
Alexandre Julliard -
Austin English -
Chris Howe -
Dan Kegel -
Dylan Smith -
James McKenzie -
Jeremy White -
Roderick Colenbrander -
Rosanne DiMesio