search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
16 Feb
2009
16 Feb
'09
10:14 p.m.
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.
17 Feb
17 Feb
12:07 p.m.
Dan Kegel <dank(a)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(a)winehq.org
12:36 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
2009/2/17 Alexandre Julliard <julliard(a)winehq.org>
Dan Kegel <dank(a)kegel.com> writes:
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
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. 
2:27 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Tue, Feb 17, 2009 at 6:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
Dan Kegel <dank(a)kegel.com> writes:
What happened to 'bug for bug compatibility'?
--
-Austin
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(a)winehq.org
2:31 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Tue, Feb 17, 2009 at 4:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
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
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.
2:47 p.m.
Dan Kegel <dank(a)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.
--
Alexandre Julliard
julliard(a)winehq.org
2:57 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
No. Find a better way.
For instance, investigate the possibility of checking version
resources.
Which version resources are you thinking of?
3:10 p.m.
Dan Kegel <dank(a)kegel.com> writes:
On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard
<julliard(a)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'm sure there are other
possibilities too.
--
Alexandre Julliard
julliard(a)winehq.org
No. Find a better way.
For instance, investigate the possibility of checking version
resources.
Which version resources are you thinking of?
3:12 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Tue, Feb 17, 2009 at 7:10 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
Oh. Thanks for the hint!
- Dan
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.
27 Feb
27 Feb
8:14 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Tue, Feb 17, 2009 at 7:10 AM, Alexandre Julliard <julliard(a)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 */
+
11:02 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Fri, Feb 27, 2009 at 3:14 PM, Dan Kegel <dank(a)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
28 Feb
28 Feb
1:32 a.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Fri, Feb 27, 2009 at 3:02 PM, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote:
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
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
7:58 a.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Fri, Feb 27, 2009 at 8:32 PM, Dan Kegel <dank(a)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.
17 Oct
17 Oct
3:10 a.m.
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 );
4:15 a.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
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(a)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 );
1:31 p.m.
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
3:22 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Sat, Oct 17, 2009 at 6:31 AM, Jeremy White <jwhite(a)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
3:35 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Sat, Oct 17, 2009 at 5:22 PM, Dan Kegel <dank(a)kegel.com> wrote:
On Sat, Oct 17, 2009 at 6:31 AM, Jeremy White
<jwhite(a)codeweavers.com> wrote:
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
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.
4:35 p.m.
Jeremy White <jwhite(a)codeweavers.com> writes:
Dan Kegel wrote:
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.
--
Alexandre Julliard
julliard(a)winehq.org
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.
4:43 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Sat, Oct 17, 2009 at 9:35 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
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.)
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.
4:53 p.m.
Dan Kegel <dank(a)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
julliard(a)winehq.org
18 Oct
18 Oct
1:33 a.m.
Alexandre Julliard wrote:
Dan Kegel <dank(a)kegel.com> writes:
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
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.
8:12 a.m.
Jeremy White <jwhite(a)codeweavers.com> writes:
Alexandre Julliard wrote:
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.
--
Alexandre Julliard
julliard(a)winehq.org
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)? 
17 Oct
17 Oct
7:12 p.m.
Dan Kegel wrote:
On Fri, Feb 27, 2009 at 3:02 PM, Dylan Smith
<dylan.ah.smith(a)gmail.com> wrote:
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
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
7:28 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Sat, Oct 17, 2009 at 12:12 PM, James McKenzie
<jjmckenzie51(a)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?
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 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.
17 Feb
17 Feb
4:10 p.m.
New subject: 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?
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.
4:33 p.m.
New subject: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
On Tue, Feb 17, 2009 at 8:10 AM, Rosanne DiMesio <dimesio(a)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
5310
days inactive
5554
days old
26 comments
9 participants
participants (9)
-
Alexandre Julliard -
Austin English -
Chris Howe -
Dan Kegel -
Dylan Smith -
James McKenzie -
Jeremy White -
Roderick Colenbrander -
Rosanne DiMesio