Re: Another pack4 issue (fwd)

[Dmitry Timoshkov]

"Francois Gouget"  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.