Need help in debugging a stack corruption

[Lionel Ulmer]

On Sat, Jan 07, 2006 at 12:02:27PM +0100, Stefan Dösinger wrote:
> When creating the Interface, I allocate a I<Interface>Impl structure, and I 
> assign the VTable of the requested version:
> 
> if(DD7) 
> 	object->lpVtbl = &IDirectDraw7_Vtbl;
> else if(DD4)
> 	(IDirectDraw4Vtbl *) object->lpVtbl =  &IDirectDraw4_Vtbl;
> else if(DD2)
> 	(IDirectDraw2Vtbl *) object->lpVtbl =  &IDirectDraw2_Vtbl;
> else if(DD1)
> 	(IDirectDrawVtbl *) object->lpVtbl = &IDirectDraw1_Vtbl;

Well, an object can have multiple interfaces and still be the same object.
So basically if at each new 'QueryInterface' call you allocation a new
I<Interface>Impl structure it's wrong regarding COM too...

For example, you could create a surface1, query interface it to be a
surface2. Then if you changed stuff using the 'surface1' methods (like, for
example, attaching a palette to it), you should be able to query the same
palette back using the 'surface2' methods ... Which would not be the case
using your solution as both interfaces have separate contexts.

So your object need to have all vtables set at the beginning and the only
difference between the interfaces is the pointer returned to the application.

> What are the advantages of this?
> * No need for the Thunk_I<Interface>_<Method> functions, except for 
> IDirectDraw::SetDisplayMode. The app calls directly into the methods.
> * No need for the ICOM_THIS_FROM, COM_INTERFACE_CAST, ... Makros.
> * No difference between the Implementation address and the address passed to 
> the app. This makes traces easier to read IMO.

Yeah but all this is wrong and does not respect what COM is... I did not
spend hours writing the Python script that auto-generated most of the
initial code for nothing :-)

         Lionel

PS: actually at the beginning of the rewrite we toyed with removing the
    thunks and adding a pointer to the object data after each VTable. This
    would have removed all the ICOM_THIS_FROM stuff as getting the address
    of the object itself would just have been to read the 4 bytes after the
    VTable. As this idea was frowned upon by AJ, we went the thunks way :-)

-- 
		 Lionel Ulmer - http://www.bbrox.org/