Hello Jeremy, Juan and rest of wine-devel [sorry for shifting quotes around, this makes following my points easier and in this case shouldn't forge you to seem to have said something you didn't say]
And now that I know that, I certainly won't be doing it again.
Thank you for your understaning.
Another "Thank you" from here.
If I provided a patch to dlls/oleaut32/tests/olepicture.c adding tests that verify the behaviors of the functions, would that be accepted?
In general, writing tests is okay, as they are an exercise in black-box reverse engineering, which is what's allowed. So yeah, tests would be great.
Would it be acceptable for me to write up a description of what the function needs to do, so that someone else can do a clean-room implementation?
I think that would be acceptable, yes. We have implemented things with hints from people who've studied disassembly before. Do you have a bug open? Sorry, I've forgotten. If not, please do open one. You can describe your findings there.
The best way to do this is (in my oppinion) submitting the testcase again, but without the implementation, and marking the test todo_wine. A bug might be useful, but wouldn't a mail that contains the testcase as patch and the description in the comment part to wine-patches suffice? Be sure to write your findings like (this is hypothetical, as I did not look at your patches and the OlePicture stuff till now): "Loads an image from a File. This is just like OleLoadPictureStream, but with a file name instead of a stream as source specification" and not like "To implement the function, you must create a stream from the file (use the standard OLE file stream object for that), pass the stream to OleLoadPictureStream and finally release the stream. In the error case you should do foo". The second form *is* just publishing what you saw in disassembly, so everyone who reads this mail carefully is in my oppinion everyone reading it carefully is in the same situation as you and shouldn't implement the function. Testcases on the other hand are fine. They just describe *what* to do, but not *how*. Especially for the error case testcases might be interesting.
Is there anyone out there who would volunteer to do it if I were to write a description of the function?
I would do so, if its just some minutes.
Regards, Michael Karcher