[PATCH] msxml3: Allow DOMDocument in VT_DISPATCH slot for put_output.
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. 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. thanks, Jefferson [1] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms756987(...
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.
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.
thanks, Jefferson
[1] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms756987(...
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
participants (2)
-
Jefferson Carpenter -
Nikolay Sivov