spec file syntax for VARIANT parameter
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 [EMAIL PROTECTED]' undefined reference to [EMAIL PROTECTED]' Looking at the functions that are present in the .o file, I see they are really [EMAIL PROTECTED] and [EMAIL PROTECTED] 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
Re: spec file syntax for VARIANT parameter
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 [EMAIL PROTECTED]' undefined reference to [EMAIL PROTECTED]' 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
