"Francois Gouget" <[EMAIL PROTECTED]> 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.
