2008/11/17 Michael Karcher wine@mkarcher.dialup.fu-berlin.de:
Am Montag, den 17.11.2008, 13:09 -0800 schrieb Jeremy Drake:
As far as the "standard OLE file stream object", if you know of one please let me know. AFAIK, it is a pretty major oversight in the OLE IStream APIs that there is not a function to create an IStream given a file (name or handle).
Oops. I just assumed there was one, but you seem to be right.
In shlwapi there is a SHCreateStreamFromFile with A, W and Ex versions when given a filename.
Quite. Also in olectl.h are the error codes that these functions could return. Unfortunately, I think it will be necessary to make some sort of manual translation between the GetLastError returns from the file APIs and these errors. Without spelling out the mappings from the disassembly, it will probably be nearly impossible to get all of the cases exactly right.
That is fair. Even different Windows versions are some times inconsistent with their error codes. It is more important what conditions exactly count as errors, and what happens to the data pointed to by lplpdispPicture parameter (unchanged / set to NULL / set to a valid object implementing IDispatch and IPicture). Most prominent error codes like "File not found" and "File is not in any supported format" should be checked, but that's it. You shouldn't even have told that the mapping is done directly in OleLoadPictureFile and not some lower layer invoked by OleLoadPictureFile, except if you are sure from a relay trace. Of course, if Wine developers find that *somewhere* error codes seem to be mapped, they are free to do the mapping in OleLoadPictureFile.
There should not be any mapping of error codes, except where tests clearly show what is returned and that does not match what is returned by the APIs being called to implement the function. Some of the errors - such as "file not found" can be handled by the called APIs like SHCreateStreamOnFile. There should still be tests for these codepaths as well.
FWIW, applications are not usually concerned with the specifics of why an API failed, just that it did. This, in addition to Windows changing the return codes every release means that the error codes returned won't make that big a difference; the only error codes you can rely on will be those listed in the MSDN documentation.
- Reece