Re: [PATCH] msxml2: Share source with msxml3

[Alexandre Julliard]

Alistair Leslie-Hughes  writes:
> Signed-off-by: Alistair Leslie-Hughes
>
> 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?

[PATCH] msxml2: Share source with msxml3

[Alistair Leslie-Hughes]

On 26/07/16 20:43, Alexandre Julliard wrote:
> Alistair Leslie-Hughes  writes:
> > Signed-off-by: Alistair Leslie-Hughes
> >
> > 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

[PATCH] msxml2: Share source with msxml3

[Alexandre Julliard]

Alistair Leslie-Hughes  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
> - Clean prefix.
> - Install native msxml3
> - 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...