Another pack4 issue (fwd)

Dmitry Timoshkov dmitry at baikal.ru
Thu Nov 22 20:05:06 CST 2001


"Francois Gouget" <fgouget at free.fr> wrote:

> [...]
> > What is really fun, that usage of FILETIME instead of LARGE_INTEGER leads
> > to differences in size of structures.
> 
>    That's very strange. It would be good to understand why because this
> should not happen.

Any ideas, why does it happen? Is it due to the LONGLONG usage?

> -        if (ft) *ft = info->LastWriteTime;
> +        if (ft) *ft = *(FILETIME *)&info->LastWriteTime;
> 
> 
>    This cast should not be necessary. Both sides are FILETIMEs.

It's because according to ntddk.h from NT4 DDK info->LastWriteTime
is LARGE_INTEGER. Please look at my patch a bit carefully.

> -    FILETIME modif;
> +    LARGE_INTEGER modif;
>  
> -    RtlSecondsSince1970ToTime( req->modif, &modif );
> +    RtlSecondsSince1970ToTime( req->modif, (FILETIME *)&modif );
> 
> 
>    Here I don't understant why you changed modif to a LARGE_INTEGER
> since RtlSecondsSince1970ToTime takes a FILETIME*

Same comment as above.

> +    UINT    type;
> +    LPVOID  pvFilter;
>  } HDITEMA, *LPHDITEMA;
> 
>    I don't see these two fields on Windows. Same thing for the W
> version. That's with the VC 6 headers.

It's in July 2000 PlatformSDK as well as in MSDN online.

>  typedef struct {
>      DWORD cb;
> -    BYTE DeviceName[32];
> -    BYTE DeviceString[128];
> +    CHAR DeviceName[32];
> +    CHAR DeviceString[128];
>      DWORD StateFlags;
> +    CHAR DeviceID[128];
> +    CHAR DeviceKey[128];
>  } DISPLAY_DEVICEA,*PDISPLAY_DEVICEA,*LPDISPLAY_DEVICEA;      
> 
> 
>    Hmm, no. It is 'BYTE' on Windows. And I don't see the two extra
> fields either.

Same comment as above.

> +
> +    BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
>  } CONTEXT86;
> 
>    I don't have this field in CONTEXT86, but it is there in
> CONTEXT. It seems that it's our definition of CONTEXT which is wrong:
> typedef CONTEXT86 CONTEXT;

Same comment as above.

>  typedef struct _IMAGE_BASE_RELOCATION
>  {
>   DWORD VirtualAddress;
>   DWORD SizeOfBlock;
> +#ifdef __WINE__
>   WORD TypeOffset[1];
> +#endif
>  } IMAGE_BASE_RELOCATION,*PIMAGE_BASE_RELOCATION;
> 
>    Do we handle this correctly in the code? I.e. is there APIs where the
> application gives us a pointer to a struct without the field and we
> write to it? I wonder how this is supposed to work.

In winnt.h from the PlatformSDK it is just commented, but as you could assume
Wine loader uses this field to relocate images.

> +#include "pshpack4.h"
>  typedef struct _LUID_AND_ATTRIBUTES {
>    LUID   Luid; 
>    DWORD  Attributes; 
>  } LUID_AND_ATTRIBUTES; 
> +#include "poppack.h"
> 
>    Is this really necessary? LUID is 8 bytes so the DWORD should be
> aligned just fine with or without the pack4...

Without pshpack4.h sizeof(LUID_AND_ATTRIBUTES)=16 instead of 12. Don't ask
me why. Both NT4 DDK (ntddk.h) and PlatformSDK (winnt.h) headers surround
LUID_AND_ATTRIBUTES definition by "pshpack4.h"/"poppack.h" pair.

Thanks for your comments.

--
Dmitry.





More information about the wine-devel mailing list