On Sunday 16 January 2005 14:58, Mike Hearn wrote:
On Sat, 15 Jan 2005 22:35:04 +0200, Antti Mäkelä wrote:
0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd64b4 L"Lab
..snip..
0009:Call user32.LoadStringA(67f00000,00000088,7796c3d0,00000100) ret=67f8cfd5
This is where the error occurs ... it's loading the error message from the resource file. So you can ignore the rest of this section.
Unfortunately that trace doesn't reveal very much. One thing I do notice is that the string being converted isn't valid XML. It seems to have been
The entire exchange, as seen by ethereal is (Follow TCP stream-option):
GET /fworder/fwver.asp?LID=1100&OEM=1100&UPID=1100&VER=3.1.139.1&RD=83bd HTTP/1.0 Accept: text/* User-Agent: fwPrint Cookie: Host: master.fotowire.com
HTTP/1.1 200 OK Connection: close Date: Sun, 16 Jan 2005 13:21:56 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 1.1.4322 Cache-Control: no-cache Pragma: no-cache Expires: -1 Content-Type: text/xml; charset=utf-8 Content-Length: 416
<?xml version="1.0"?> <update><validity>2005/1/21</validity><package><title>Lab Logo 1</title><date>1997/11/26</date><url>/labs/logos/1100/2.jpg</url><destination>$data$/lab.fw1</destination><method>2</method><type>2</type></package><package><title>Lab Logo 2</title><date>1997/11/26</date><url>/labs/logos/1100/6.jpg</url><destination>$data$/lab.fw2</destination><method>2</method><type>2</type></package></update>
chopped off a bit. So the question is, where does this string come from? If it's a wininet thing then it may be that we're not downloading the remote page correctly. Does native wininet help?
With native wininet.dll (again, from win2k SP4) when the connection initiates, I get an exception and it drops top winedbg.
bash-2.05b$ wine fwPrint fixme:ole:StdMarshalImpl_MarshalInterface table marshalling unimplemented wine: Unhandled exception (thread 0013), starting debugger... WineDbg starting on pid 0xf Unhandled exception: page fault on read access to 0x00000002 in 32-bit code (0x77ddea9b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:77ddea9b ESP:7c65e970 EBP:00000000 EFLAGS:00010202( - 00 - -RI1) EAX:00000002 EBX:7c65eaa0 ECX:0000005c EDX:00000000 ESI:77ccfc80 EDI:00000000 Stack dump: 0x7c65e970: 00000030 7c65e984 77ddea6c 77ddea50 0x7c65e980: 00000000 77213a63 6f646e69 74217377 0x7c65e990: 6f706d65 79726172 746e6920 656e7265 0x7c65e9a0: 69662074 2173656c 746e6f63 2e746e65 0x7c65e9b0: 21356569 0000c000 00000000 00000000 0x7c65e9c0: 00000000 00000000 00000000 77efd488 Backtrace: =>1 0x77ddea9b (0x00000000) 0x77ddea9b: adcb 0x0(%eax),%al Wine-dbg>
Anyway, regarding the validity of XML, the first reference to the entire response from the server is following:
0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd62de L"1.0"?>\r\n<update><validity>2005/1/21</validity><package><title>Lab Logo 1</title><date>1997/11/26</date><url>/labs/logos/1100/2.jpg</url><destination>$data$/lab.fw1</destination><method>2</method><type>2</type></package><package><title>Lab Logo 2</title><date>1997/11/26</date><url>/labs/logos/1100/"...,00000003,7defb010,00000007,00000000,00000000) ret=67f852e8
Next WideCharToMultiByte call is
0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd62f0 L"update><validity>2005/1/21</validity><package><title>Lab Logo 1</title><date>1997/11/26</date><url>/labs/logos/1100/2.jpg</url><destination>$data$/lab.fw1</destination><met hod>2</method><type>2</type></package><package><title>Lab Logo 2</title><date>1997/11/26</date><url>/labs/logos/1100/6.jpg</url><"...,00000006,7defb150,0000000d,00000000,00000000) ret=67f852e8
And so it goes, always stripping the first tag away. The full XML string is not shown in the log entries (I think, note the ...). When the tags from the beginning are stripped away, more stuff from the end shows up in the log. A few lines later there is
0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd63e6 L"url><destination>$data$/lab.fw1</destination><method>2</method><type>2</type></package><pack age><title>Lab Logo 2</title><date>1997/11/26</date><url>/labs/logos/1100/6.jpg</url><destination>$data$/lab.fw2</destination><method>2</method><type>2</type></package></update>",00000003,7defb290,00000007,00000000,00000000) ret=67f852e8
that does show the contents all the way to the end (the </update> tag).
Final call is
0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd65f2L"update>",00000006,7defb5b0,0000000d,00000000,00000000) ret=67f852e8
At this point it seems that the information is parsed from XML Tags.
After this is done comes the parts in the log I note in my earlier message (the second snippet, with oleaut32.VarDateFromStr call).
What seems to be happening (to me) is that this program is a bit dirty: In effect the parsing process just finds the next '<' in a string, takes the tag, finds next >, and store the entire rest of the string beginning from the next char and does not even bother to cut it off.
This could explain why the next call is as follows:
0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd6312 L"2005/1/21</validity><package><title>Lab Logo 1</title><date>1997/11/26</date><url>/labs/logos/1100/2.jpg</url><destination>$data$/lab.fw1</destination><method>2</method><ty pe>2</type></package><package><title>Lab Logo 2</title><date>1997/11/26</date><url>/labs/logos/1100/6.jpg</url><destination>$data"...,00000009,7defb5b0,00000013,00000000,00000000) ret=67f852e8
In effect, now we're trying to process the date information (2005/1/21). The variable (or whatever) that supposedly contains the information also has the entire rest of the original XML string.
0009:Ret kernel32.WideCharToMultiByte() retval=00000009 ret=67f852e8
This is the return value, I'm assuming that the original call specified either the delimiter or something so only the first 9 characters are returned..
And so we get to the date: 0009:Call oleaut32.VarDateFromStr(7796c4a0 L"2005/1/21",00000409,00000002,7796ca20) ret=67f596c9
Also the first call you quoted is part of the process doing this too - the program at that point is only interested in the string "Lab Logo 2", the rest of the stuff can just go away..
The stuff about GetLocaleInfoW is a bit more interesting. Maybe the date format is locale-specific and Wine implementation cannot parse it?
There may be a problem here ... some test cases may reveal the issue.
I'm thinking that the XML parsing is probably not the problem (see above), so I would like to pursue this approach. What tests cases could I try out?