On Tue, Aug 16, 2005 at 04:33:36PM +0200, Francois Gouget wrote:
I checked the prototypes of OleDoAutoConvert() and GetConvertStg() and they use LPSTORAGE rather than IStorage* so I think the 16bit versions should match. This would avoid introducing ISTorage* in win16.api.
However one could probably also argue that these functions (which are currently just stubs) should take a SEGPTR anyway...
This brings me to OleLoad16() and ReadClassStg16() which were causing winapi_check to complain because they have comments in their prototypes that look like documentation to it. I think the right way to handle those is use the regular documentation to document the real type of these pointers, i.e. do it as follows:
The LPSTORAGE layout is definitely not the same.
So LPSTORAGE16 would be more fitting I think.
Also when not using "SEGPTR" I get conversion warnings and it clarifies a bit what exactly the type of the argument is.
I am fine by the patch, but will have to fix it up regarding LPSTORAGE once we get to the point of implementing those funcs.
Ciao, Marcus
On Tue, 16 Aug 2005, Marcus Meissner wrote: [...]
The LPSTORAGE layout is definitely not the same.
What do you mean? I just replaced 'IStoreage *' with 'LPSTORAGE' and since the LPSTORAGE declaration is 'typedef IStorage *LPSTORAGE;' the layout should be the same. Now if the original prototype was wrong for some other reason that's another issue.
So LPSTORAGE16 would be more fitting I think.
You mean in the documentation?
Also when not using "SEGPTR" I get conversion warnings and it clarifies a bit what exactly the type of the argument is.
Do you mean it would be better not to use 'SEGPTR' in the prototypes?
On Wed, Aug 17, 2005 at 12:31:36AM +0200, Francois Gouget wrote:
On Tue, 16 Aug 2005, Marcus Meissner wrote: [...]
The LPSTORAGE layout is definitely not the same.
What do you mean? I just replaced 'IStoreage *' with 'LPSTORAGE' and since the LPSTORAGE declaration is 'typedef IStorage *LPSTORAGE;' the layout should be the same. Now if the original prototype was wrong for some other reason that's another issue.
For the 32bit functions use of "LPSTORAGE" is fine.
For the 16bit functions I do not know. The interface itself is the same, but the calling conventions really are not.
So this is more of a programming detail.
So LPSTORAGE16 would be more fitting I think.
You mean in the documentation?
In the documentation I guess it is ok.
Also when not using "SEGPTR" I get conversion warnings and it clarifies a bit what exactly the type of the argument is.
Do you mean it would be better not to use 'SEGPTR' in the prototypes?
No, I meant that I did switch to SEGPTR because of it.
Anyway, its fine as is. :)
Ciao, Marcus
On Wed, 17 Aug 2005, Marcus Meissner wrote: [...]
So LPSTORAGE16 would be more fitting I think.
You mean in the documentation?
In the documentation I guess it is ok.
Hmm, now I see that IStorage16 and LPSTORAGE16 are defined in dlls/ole32/ifs.h and the structures they point to probably don't have the same layout as their 32bit equivalents. So it would probably make more sense to refer to those types in the documentation. Would the attached patch be ok?
(LPOLECLIENTSITE16 is not defined yet in ifs.h or elsewhere but I guess that will come)
On Wed, Aug 17, 2005 at 09:13:46AM +0200, Francois Gouget wrote:
On Wed, 17 Aug 2005, Marcus Meissner wrote: [...]
So LPSTORAGE16 would be more fitting I think.
You mean in the documentation?
In the documentation I guess it is ok.
Hmm, now I see that IStorage16 and LPSTORAGE16 are defined in dlls/ole32/ifs.h and the structures they point to probably don't have the same layout as their 32bit equivalents. So it would probably make more sense to refer to those types in the documentation. Would the attached patch be ok?
The structs have the same source layout (same function order, same arguments), but different calling conventions (32 stdcall vs 16 bit). I have to define them differently in WINE at least.
Its ok.
(LPOLECLIENTSITE16 is not defined yet in ifs.h or elsewhere but I guess that will come)
When it is needed ... the program I have currently does not need further OLE handholding.
Ciao, Marcus
-
Francois Gouget -
Marcus Meissner