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

[Michael Karcher]

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