Several msxmlX modules

[Nikolay Sivov]

On 2/2/2010 20:28, Reece Dunn wrote:
> On 2 February 2010 16:19, Nikolay Sivov<bunglehead at 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
>
>