Is the DECIMAL variant type too long ?

[gerard patel]

After the following patch :

ChangeSet ID:   989259340138108821120113
CVSROOT:        /opt/cvs-commit
Module name:    wine
Changes by:     julliard@wine2. 01/05/07 14:15:40

Modified files:
        include        : oleauto.h wtypes.h 
        include/wine   : obj_base.h obj_oleaut.h

Log message:
        Francois Gouget 
        Added support for the DECIMAL type.
        Names are no longer suffixed with 32! Removed it.

Borland Builder 4 crashes while starting :-/

Tracing the crash shows that it hangs  immediately
after the *first* variant Api access :

Call oleaut32.VariantCopyInd(405869b0,40586974) ret=405b2e6b tid=08065a10
trace:ole:VariantCopyInd (0x405869b0, 0x40586974)
trace:ole:VariantCopy (0x405869b0, 0x40586974)
trace:ole:VariantClear (0x405869b0)
Ret  oleaut32.VariantCopyInd() retval=00000000 ret=405b2e6b tid=08065a10
Call oleaut32.VariantChangeTypeEx(40586968,405869b0,00000400,00000000,00000003) ret=405b301c tid=08065a10
trace:ole:VariantInit (0x4058685c),stub
trace:ole:VariantChangeTypeEx (0x40586968, 0x405869b0 (11), 1024, 0, 3),stub
trace:ole:VariantClear (0x40586968)
trace:ole:VarI4FromBool ( -1, 0x40586970 ), stub
trace:ole:VariantClear (0x4058685c)
Ret  oleaut32.VariantChangeTypeEx() retval=00000000 ret=405b301c tid=08065a10
err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception.

I have changed the trace slightly, the 11 listed for the VariantChangeTypeEx shows
that the original type is a boolean. The call is trying to change a boolean (11) into
an integer (3).

The changes in include/wtypes.h are the important ones.

Replacing the new DECIMAL type by

typedef struct tagDEC {
    BYTE aa[2];
} DECIMAL;

get rid of the crash. 
If I make the byte array 16 bytes long, same crash as the current Wine behaviour.
If I make it 10 bytes long, access violation.
If I make it 8 bytes long, it works too.

Could the DECIMAL type be a pointer to the real data ??

Gerard

[Francois Gouget]

On Thu, 10 May 2001, gerard patel wrote:
[...]
> Could the DECIMAL type be a pointer to the real data ??

No. The problem is the tagVARIANT type:
sizeof(DECIMAL) -> 16 in Windows, 16 in Wine
sizeof(VARIANT) -> 16 in Windows, 24 in Wine

Oups, that's where the problem is. In Windows DECIMAL is not at the
same level as the other fields. It's part of an englobing union: you
basically have:

union {
       struct {
           VARTYPE vt;
           WORD wReserved1;
           WORD wReserved2;
           WORD wReserved3;
           union {
               lots of fields...
           }
       }
       DECIMAL decVal;
   }

In Wine decVal is with the other variant fields so the total size of
VARIANT is 2+2+2+2+16 -> 24

Temporary fix: comment out decVal.
   Correct fix: add the global union and update lots of places in Wine
to match. Plus on Windows, just for VARIANT, they use n1, n2, n3 as the
dummy union/struct names.

Hmm... this must be breaking lots of things, sending the quick fix to
wine-patches.

Any volunteer for the right fix?

--
Francois Gouget         [e-mail]        http://fgouget.free.fr/
 Advice is what we ask for when we already know the answer but wish we didn't
                                 -- Eric Jong