Re: [PATCH] msxml2: Share source with msxml3
Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes:
Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- dlls/msxml2/Makefile.in | 49 ++++++++++++++++++++++++++++++++++++-- dlls/msxml2/main.c | 63 ------------------------------------------------- dlls/msxml2/msxml2.spec | 2 +- 3 files changed, 48 insertions(+), 66 deletions(-) delete mode 100644 dlls/msxml2/main.c
Is there a real need for this? -- Alexandre Julliard julliard(a)winehq.org
On 26/07/16 20:43, Alexandre Julliard wrote:
Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes:
Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- dlls/msxml2/Makefile.in | 49 ++++++++++++++++++++++++++++++++++++-- dlls/msxml2/main.c | 63 ------------------------------------------------- dlls/msxml2/msxml2.spec | 2 +- 3 files changed, 48 insertions(+), 66 deletions(-) delete mode 100644 dlls/msxml2/main.c
Is there a real need for this?
yes and no. Since msxml2/4/6 all point to msxml3, having to install native msxml3 will cause all the rest to fail. As an example, mdac28 requires msxml3 to be installed (msxml3 has an incomplete IXMLParser implementation, so native has to be used). I would change msxml4/6 as well, so that installing any of the native msxml DLL wouldn't affect the others. We could just use my previous patch, which would also resolve the issue of registry entry. That scenario is 1. Clean prefix. 2. Install native msxml3 3. Force update of bottle (e.g. wine update) The msxml2.DOMDocument registry entry is now incorrect. (this would still fail if you want to create an Msxml2.DOMDocument.4.0 object) Best Regards Alistair Leslie-Hughes
Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes:
Since msxml2/4/6 all point to msxml3, having to install native msxml3 will cause all the rest to fail. As an example, mdac28 requires msxml3 to be installed (msxml3 has an incomplete IXMLParser implementation, so native has to be used). I would change msxml4/6 as well, so that installing any of the native msxml DLL wouldn't affect the others.
We could just use my previous patch, which would also resolve the issue of registry entry. That scenario is 1. Clean prefix. 2. Install native msxml3 3. Force update of bottle (e.g. wine update) The msxml2.DOMDocument registry entry is now incorrect.
That's a corner case that I don't think justifies duplicating such a large dll 4 times. It should be easy to avoid by using native for the other ones too. And of course fixing builtin would be even better... -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Alistair Leslie-Hughes