On 2/2/2010 20:28, Reece Dunn wrote:
On 2 February 2010 16:19, Nikolay Sivovbunglehead@gmail.com wrote:
Hi.
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.
http://msdn.microsoft.com/en-gb/library/ms753751%28VS.85%29.aspx ["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 interface.
If there's no such property in earlier versions there's no reason for app to use it, there's practically can't happen in real world application. But it's of course a proper way.
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?
No. I mean does it make sense to even add new modules. A proper way is to forward with registry settings set, so it shouldn't even matter how module's named.
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.
The 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).
Because on windows registry entry for Document4 points to msxml4, not 3 or something else.
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 (obviously).
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 different.
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).
Both are too complicated. It seems it's enough to have one winexml and almost empty modules for msxmlX with DllGetClassObject forwarded to winexml, and common server registration helpers to place registry data.
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.
I can place all tests to lower possible msxmlX module (after separation to winexml) to let automated tests run on all boxes. Testing new functionality with earlier interfaces is a next step.
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 property [http://msdn.microsoft.com/en-gb/library/ms762632%28VS.85%29.aspx] in msxml 6, and default this to false for earlier versions for example.
No need to care of differences between version for a start, will be ideally not to check for version at all. And yes, winexml should be superset of course.
- Reece