Several msxmlX modules
msclrhd at googlemail.com
Tue Feb 2 11:28:00 CST 2010
On 2 February 2010 16:19, Nikolay Sivov <bunglehead at gmail.com> wrote:
> Wine currently has only one module for MSXML parser - msxml3. Since the
> third one v4 and v6 are already out.
There is also an msxml 5. This is only available via Office 2003/2007,
and is installed by that. See http://support.microsoft.com/kb/269238
["List of Microsoft XML Parser Versions"].
> Judging from file size I don't think native modules reuse some code between
> them, instead it looks like a completely
> independent builds.
["What's new on msxml"] gives an overview of the features introduced
by the different versions of msxml.
For example, msxml 4 has a new parser that is enabled by the
setProperty("NewParser", true) call on the MSXML DOMDocument
> What Wine's policy should be about that? Is that really necessary to have
> several modules to
> look like native does (forwarding class creation to msxml3 of course)?
You mean if an application calls CoCreateInstance on an msxml 4
document, it will create an msxml 3 document?
This will break applications that depend on things like the XPath
property introduced in msxml 4, and adding support for that does not
make sense in msxml 3.
> other way is a bit misleading -
> having msxml3 that responds to v4 interface creation I mean (and lot of
> application depend on version fourth today).
Why? Generally speaking, the later versions of msxml are supersets of
the older versions (i.e. they can be used without modification for the
newer versions, aside from the CLSID used).
> After that I thought about renaming msxml3 to msxml but I'm not sure that
> won't break some apps.
> I'd like to see some opinions on this.
The main things to deal with are the areas where the msxml versions
are common to each other, and where the msxml versions are different
As I see it, there are two main approaches that can be taken:
1/ the wined3d model
That is... create a winexml (that is taken from the current msxml3),
and have msxml3, 4, 5? and 6 that expose the correct COM API and
forward the requests to the winexml version that supports everything
that the msxml versions support. These will also provide appropriate
checking for the setProperty call and any other APIs that are
2/ a latest version with wrappers for older versions
This is similar to the wined3d model, but having msxml6 (or whichever
is the latest version) as the equivalent of wined3d. The older
versions will then be wrappers around the msxml6 API that limit the
functionality accordingly, and implement any functionality dropped in
the newer version.
This may end up being a cascade, as for example, XDR Schema support
has been dropped in msxml 6, so msxml 3 would need to wrap msxml 4
(which wraps msxml 6 and supports XDR Schemas).
With this in mind, it is probably better to go with the wined3d model.
You will also need decent tests for msxml 4, 5? and 6. The msxml 3
tests should cover functionality (like the new properties such as
NewParser) to see how it behaves in these situations.
Q: Are you aiming on bug-for-bug compatibility with XSLT and XSD support?
If so, this might be fairly tricky to cope with. It should in theory
be possible to parameterise these and perform the different quirks
based on these settings.
The core support (in winexml, or whatever is used) should support the
superset of functionality. That is, it should support the ProhibitDTD
in msxml 6, and default this to false for earlier versions for
More information about the wine-devel