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