[PATCH 1/2] [User32]: clearly separe the 16bit code out of user32

Alexandre Julliard julliard at winehq.org
Tue May 5 07:12:23 CDT 2009


Eric Pouech <eric.pouech at orange.fr> writes:

> @@ -145,14 +146,101 @@ HDDEDATA	WDML_InvokeCallback16(PFNCALLBACK pfn, UINT uType, UINT uFmt,
>      return ret;
>  }
>  
> +#define MAX_THUNKS      32
> +/* As DDEML doesn't provide a way to get back to an InstanceID when
> + * a callback is run, we use thunk in order to implement simply the
> + * 32bit->16bit callback mechanism.
> + * For each 16bit instance, we create a thunk, which will be passed as
> + * a 32bit callback. This thunk also stores (in the code!) the 16bit
> + * address of the 16bit callback, and passes it back to
> + * WDML_InvokeCallback16.
> + * The code below is mainly to create the thunks themselved
> + */
> +static struct ddeml_thunk
> +{
> +    DWORD       instId;     /*      instance ID                                     */
> +    SEGPTR      pfn16;      /*      16bit callback address                          */
> +                            /* start:                     ; 32bit callback          */
> +    BYTE        call;       /*      call get_eip                                    */
> +    DWORD       call_rel32; /*                                                      */
> +                            /* get_eip:                                             */
> +    BYTE        pop_eax;    /*      pop %eax              ; eip of get_eip          */
> +    BYTE        pop_ecx;    /*      pop %ecx              ; return address          */
> +    BYTE        push_pfn[3];/*      pushl -0x9(%eax)      ; push pfn16              */
> +    BYTE        push_ecx;   /*      pushl %ecx                                      */
> +    BYTE        push;       /*      push $DDEML_InstanceCallback16                  */
> +    DWORD       cb16;       /*                                                      */
> +    BYTE        ret;        /*      ret                   ; jmp DDEML_InstanceCal...*/
> +} *DDEML16_Thunks;

It doesn't really make sense to build position-independent code for a
thunk that is at a known address. Plus you don't even need the address,
a simple pushl $pfn16 would work just as well. Look at how winproc
thunks are done.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list