implement OleLoadPictureFile

[Michael Karcher]

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