[PATCH] msxml3: Allow DOMDocument in VT_DISPATCH slot for put_output.

[Jefferson Carpenter]

On 11/4/2021 9:17 PM, Nikolay Sivov wrote:
> 
> 
> On 11/4/21 11:58 PM, Jefferson Carpenter wrote:
>> Regarding locking the DOMDocument while it is being written to:
>>
>> It looks like DOMDocument is meant to be used in a single-threaded
>> manner[1], so it should be all right to just grab an interface and not
>> worry about threads attempting to manipulate the document while it is
>> being written to by an mxwriter.
> 
> There are freethreaded classes as well.

Ah, Wine uses the same implementation for both, I see.

> 
>>
>> For how to lock it, unless anyone has a better idea I think it would
>> work to add an IWineXMLDOMDocumentLock interface with lock() and
>> unlock() methods, and output a FIXME if this interface is unavailable.
> I think your best bet at the moment is to load whole document at once
> from stream, on endDocument. Right way would probably be similar to how
> libxml2 does it - using SAX callbacks to construct DOM tree, and then
> using SAX reader when loading from stream, or writer calling them.

Could do that, but the code would need to be re-written so that nodes 
appear as soon as the corresponding SAX methods are called on the 
writer.  (Nodes are visible as soon as startElement is called).

Did you mean "from string", not "from stream"?  The string from 
get_output could be passed to loadXML.  However struct domdoc doesn't 
have an IStream interface (It has IPersistStreamInit) to attach to the 
writer, and mxwriter doesn't have a stream interface for the document to 
load either.

Doing that actually causes Rise of Legends to be able to load the 
mission and the game works if SAXContentHandler_putDocumentLocator 
returns S_OK.  See the patch I attached on the bug [1]

[1] https://bugs.winehq.org/show_bug.cgi?id=51965