[2/3] gdiplus: fix GdipPathIterNextMarker behaviour on path without markers. fix tests.

[Nikolay Sivov]

Michael Karcher wrote:
> Am Sonntag, den 13.07.2008, 12:42 +0400 schrieb Nikolay Sivov:
>   
>> I think first of all we should choose an appropriate method to do so and 
>> only after that try to compare results with native. What do you think of 
>> that?
>>     
> That might a good approach if we want to implement some new API and want
> to do it sensibly. That's the point where design questions are asked.
> But the Wine project works the other way round: Wine is bug-for-bug
> compatible with Microsoft Windows. This means we have to design the same
> way as Microsoft, whether we think this behaviour is idiotic or not.
>
> [Next paragraph is generally about Wine development. I do not imply that
> you are going to violate the rules stated here or already have sone so.
> Its just for your (or everybody who reads this mail in the archive)
> information]
> So: First you try out what native does. And I mean *try* *out*, not
> reverse engineer by disassembling. To proof that you have tried out what
> native does, you publish your tests as wine testcases. Then you
> implement wine in a way these testcases pass. For myself, I think it is
> acceptable to implement some API without comparing to native first, if
> you get an application to run by that, *but* to get this patch included,
> you better write an API test that shows how that application used the
> API you changed (or implemented) and verifies that your implementation
> not just happen to make the application run, but really returns the same
> result as native does. If you post a patch, always be prepared to be
> asked to test further cases. It greatly increases your chance to get
> your patch committed if you add these further cases (often, they show
> deficiencies in your patch then). Modify your patch to make these tests
> pass too, or (with a convincing explanation why this would be
> out-of-scope for your patch, for example needing to implement a whole
> new thing to make it pass) include the test as todo_wine. Do never
> ignore a test request because your implementation of an API fails it. As
> explained above: The point "What nativce does is an extremely stupid way
> to handle these corner cases, my implementation if much smarter about
> it" is never valid for Wine.
>
> I made the explicit note about disassembling (be it with IDA, w32dasm or
> getting an assembler listing of Microsoft dlls with some debugger),
> because for legal reasons, developers that have seen Microsoft source or
> object code are not allowed to commit code to Wine anymore. IIRC there
> is no consensus yet to what extent this rule applies, but (IIRC again)
> the usual interpretation is you may not contribute to the dll you
> disassembled.
>
> Regards,
>   Michael Karcher
>   
All of this is absolutely clear. The only reason why my last tests fail 
was that I didn't check them on native thinking that a crossbuild is 
much complicated procedure that it is in fact.
Of course I will not reverse any Windows binary to look at it cause it's 
a direct License Agreement  violation.

With this question I didn't try to bring some incompatibility with a 
'better' implementation, not equivalent with native. Of course not. I've 
just asked the possible way to start with this problem of portable 
floating point comparison. If  I'll found that native use some 'not 
bitwise' comparison for this calls I'll have to use some comparison 
method with tolerance value(s) and then try to get the same results as 
native provides. The question was 'what method is preferable in this 
case' that's all.