Created attachment 9829 [details]
the window mentioned above

Confirming, I just saw this a few minutes ago for another demo (Worms of Armageddon), but was a bit busy and didn't file a bug for it.

Still present in current git

Doesn't even start for me in 1.1.10.

Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!

In wine 1.1.40 JSMCMastermind-dm.exe still hangs right after start. Terminal output is attached.

Created attachment 26635 [details]
Terminal output in wine 1.1.40

Still present in 1.3.33. All I get is an infinite loop of
err:msxml:doparse XML declaration allowed only at the start of the document

winetricks msxml4 does not solve the issue.

(In reply to comment #8)
> Still present in 1.3.33. All I get is an infinite loop of
> err:msxml:doparse XML declaration allowed only at the start of the document
> 

If you trace something like +wininet you'll see response as "\n<?xml..." probably. I remember we have a bug about that. msxml is failing correctly as native does (and as specification suggest).

> winetricks msxml4 does not solve the issue.

Nikolay, you're completely right. Do you have any hints about what to do next?

trace:msxml:domdoc_loadXML (0x1189df8)->(L"\n<?xml version=\"1.0\" encoding=\"UTF-16\"?>\n<dm>\n  <files>\n    <file execute=\"yes\" stamp=\"yes\">\n      <url>http://cdn.dli.trymedia.com/r/release/knowad/15d120m10e_i_1f/JSMCMastermind.exe?nva=20111202011827&amp;aff=trygames&amp;token=1767d181f7b5589933dbb</url>\n    </file>\n  </files>\n</dm" 0x66e938)
err:msxml:doparse XML declaration allowed only at the start of the document

We need to figure out where this broken stream comes from and why it contains leading return character. I don't know details unfortunately, but as a start you probably need +wininet log or something related, it's interesting to test with native modules as well to be sure.

Created attachment 37717 [details]
tcp dump

As you can see in the attached dump file the site clearly sends an extra \n at the beginning of the stream.

00a0   31 31 65 0d 0a 0a 3c 3f 78 6d 6c 20 76 65 72 73  11e...<?xml vers

I'll retest in windows later.

Maybe we should strip all space chars when header is separated from request body, or something like that, but yes, it's interesting to see a response running windows too.

Created attachment 37718 [details]
+wininet,+msxml in 1.3.33

Attached a trimmed version of +wininet,+msxml.

Windows receives the same TCP data as expected. But the program goes on and start downloading. If you can produce a small patch to trim everything before the first "<" I'll be glad to test (I tried myself but didn't find where that msxml error message is generated).

(In reply to comment #15)
> Windows receives the same TCP data as expected. But the program goes on and
> start downloading. 

Ok, that's good.

> If you can produce a small patch to trim everything before
> the first "<" I'll be glad to test (I tried myself but didn't find where that
> msxml error message is generated).

That is not a way to fix that. When msxml3 receive such broken stream it fails as it should.

So the problem is somewhere in winhttp/wininet I think.

Download starts here if I do:

winetricks wininet ie6 msxml3

Remove any part and it doesn't work..

(In reply to comment #17)
> Download starts here if I do:
> 
> winetricks wininet ie6 msxml3
> 
> Remove any part and it doesn't work..

Okay, could you attach +msxml,+tid running only 'winetricks wininet ie6'?

Created attachment 37988 [details]
+msxml,+tid after winetricks wininet ie6

This works in Windows / native msxml3


xml:=CreateOleObject('Microsoft.XMLDOM');
xml.LoadXML(#10+'<?xml version="1.0" encoding="UTF-8" ?><test>test</test>');
xml.Save('c:/testing.xml');


Saves 0 bytes with builtin msxml3


test sample: http://netikka.net/dev/xml2.exe

(In reply to comment #20)
> This works in Windows / native msxml3
> 
> 
> xml:=CreateOleObject('Microsoft.XMLDOM');
> xml.LoadXML(#10+'<?xml version="1.0" encoding="UTF-8" ?><test>test</test>');
> xml.Save('c:/testing.xml');
> 

Yeah, I tested ::load() method only, and it fails on such stream, I'll more tests.

So your test program does:

---
0009:trace:msxml:DispatchEx_GetIDsOfNames (0x134a30)->({00000000-0000-0000-0000-000000000000} 0x33eb04 1 1033 0x33eb48)
0009:trace:msxml:DispatchEx_GetDispID (0x134a30)->(L"LoadXML" 0 0x33eb48)
0009:trace:msxml:preprocess_dispex_data (0x134a30)
0009:trace:msxml:DispatchEx_Invoke (0x134a30)->(63 {00000000-0000-0000-0000-000000000000} 0 1 0x33eae0 (nil) 0x33eb10 (nil))
0009:trace:msxml:DispatchEx_InvokeEx (0x134a30)->(3f 0 1 0x33eae0 (nil) 0x33eb10 (nil))
0009:trace:msxml:domdoc_QueryInterface (0x134a30)->({2933bf96-7b36-11d2-b20e-00c04f983e60} 0x33e400)
0009:trace:msxml:domdoc_AddRef (0x134a30)->(3)
0009:trace:msxml:domdoc_loadXML (0x134a30)->(L"\n<?xml version=\"1.0\" encoding=\"UTF-8\" ?><test>test</test>" 0x33e0f8)
0009:err:msxml:doparse XML declaration allowed only at the start of the document
0009:trace:msxml:domdoc_loadXML failed to parse document
---

and after that

---
0009:trace:msxml:DispatchEx_GetIDsOfNames (0x134a30)->({00000000-0000-0000-0000-000000000000} 0x33eb04 1 1033 0x33eb48)
0009:trace:msxml:DispatchEx_GetDispID (0x134a30)->(L"Save" 0 0x33eb48)
0009:trace:msxml:DispatchEx_Invoke (0x134a30)->(64 {00000000-0000-0000-0000-000000000000} 0 1 0x33eae0 (nil) 0x33eb10 (nil))
0009:trace:msxml:DispatchEx_InvokeEx (0x134a30)->(40 0 1 0x33eae0 (nil) 0x33eb10 (nil))
0009:trace:msxml:domdoc_QueryInterface (0x134a30)->({2933bf96-7b36-11d2-b20e-00c04f983e60} 0x33e400)
0009:trace:msxml:domdoc_AddRef (0x134a30)->(3)
0009:trace:msxml:domdoc_save (0x134a30)->({VT_BSTR: L"c:/testing.xml"})
---

same sequence in a test (well, with direct calls and not IDispatch ones) results in empty file running on Windows. That's what I thought is going on, but really the problem is all about different CLSIDs that are used to create an instance.

Actually there's two CLSID_DOMDocument from different SDK headers with different values, we use the one from msxml2.idl where it's just a define for CLSID_DOMDocument2. But in xmldom.idl it's defined with proper class section using separate IID value.

I'll think how to resolve this name mess.

Created attachment 38007 [details]
patch

Please try this one for reported msxml issue.

Patch works here (for msxml issue)

msxml bug is fixed with e736c3e9837fc818ad5154e14be56fb09f11eef5.

In wine 1.5.4 the program seems to start in the console, the xml is parsed correctly but there is no progress window opened. Can anyone else test?

*** Bug 18814 has been marked as a duplicate of this bug. ***

I tested the download manager with Wine 1.5.8 and Gecko 1.6 installed.

- the application starts in the console, but it doesn't put up any windows
- after 'winetricks ie7' the application window appears, but much of its contents are missing (empty progress bar, no text at all)
- native msxml3 is needed to make the contents of the window appear. After several attempts, connecting to the server fails.
- native wininet.dll is needed to make a successful connection, and downloading the actual game.

Still in wine 1.5.26.

Hello folks,

don't recycle bugs.

--- quote ---
Nikolay Sivov 2011-12-19 13:51:41 CST

msxml bug is fixed with e736c3e9837fc818ad5154e14be56fb09f11eef5.
--- quote ---

Open a new bug if <insert whatever issue> is still present.

Please stick to _one_ issue and avoid multiple winetricks recipes (ie7, msxml, wininet).
Also be sure to add _working_ downlink link.

Regards

Closing bugs fixed in 1.7.10.