In order to implement OleLoadPictureFile and OleLoadPictureFileEx, it will be necessary to change their entries in oleaut32.spec from stub to stdcall. The stdcall syntax wants a list of parameter types, which puts these functions in an unususal situation: they take a VARIANT (which is a struct, in case anyone is not familiar) by value as their first parameter. There does not seem to be any type defined in the spec file that fits this situation. I have been using ptr in my last couple of patches which add stub implementations for these functions, but when I tried to build this on cygwin I got errors like: undefined reference to `_OleLoadPictureFileEx@20' undefined reference to `_OleLoadPictureFile@8'
Looking at the functions that are present in the .o file, I see they are really _OleLoadPictureFileEx@32 and _OleLoadPictureFile@20. Changing the spec file to list each VARIANT as 4 longs fixes these errors.
My question is, should my next version of the patch list the VARIANT as 4 longs, or is there some better way to specify this that I'm not aware of? If not, is there a comment syntax for the spec file where I can explain why there are 4 long params where there should be one VARIANT?
Thanks Jeremy
On Wed, Nov 19, 2008 at 01:11:05PM -0800, Jeremy Drake wrote:
In order to implement OleLoadPictureFile and OleLoadPictureFileEx, it will be necessary to change their entries in oleaut32.spec from stub to stdcall. The stdcall syntax wants a list of parameter types, which puts these functions in an unususal situation: they take a VARIANT (which is a struct, in case anyone is not familiar) by value as their first parameter. There does not seem to be any type defined in the spec file that fits this situation. I have been using ptr in my last couple of patches which add stub implementations for these functions, but when I tried to build this on cygwin I got errors like: undefined reference to `_OleLoadPictureFileEx@20' undefined reference to `_OleLoadPictureFile@8'
Hmm, use as much "long" specifiers to fit the VARIANT struct (number of bytes/4). I think VARIANT has 16 byte, so use "long long long long".
My question is, should my next version of the patch list the VARIANT as 4 longs, or is there some better way to specify this that I'm not aware of? If not, is there a comment syntax for the spec file where I can explain why there are 4 long params where there should be one VARIANT?
Currently no other way.
Ciao, Marcus
-
Jeremy Drake -
Marcus Meissner