I'm having some crashes and errors from 64-bit Windows builds that use the JWA units. I've tracked it down to record alignment (the 32-bit version works fine, so it's the first place I looked). I notice that there's no {$packrecords c} anywhere (or alternatively {$align 8} for 64-bit). Am I missing something? I'm having trouble believing that no one has found this before.

Henry

Op 2020-05-14 om 15:53 schreef Henry Vermaak via fpc-devel:

The original headers only did 32-bit. Over the years some 64-bit corrections have been added. This process is ongoing, so please make sure you use the newest version.

I'm a bit loath to try to fix this with big, overarching $packrecords, because the winapi actually sometimes uses packrecords C and sometimes packrecords 8.

Similar attempts in the normal windows headers were cumbersome, so we are dealing with it on a case by case basis.

If you have problems with certain structures, AND you have tested with trunk or FPC 3.2.0rc1, please file a bug.

Marco van de Voort wrote

The original headers only did 32-bit. Over the years some 64-bit corrections have been added. This process is ongoing, so please make sure you use the newest version.

Grepping for align|packrecords give exactly the same results in trunk, afaics. jwawindows.pas explicitly sets align 4.

I'm a bit loath to try to fix this with big, overarching $packrecords, because the winapi actually sometimes uses packrecords C and sometimes packrecords 8.

So why is rtl/win*/* full of packrecords c? These pages say that the Windows API expect 8:

https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers#controlling-structure-packing https://docs.microsoft.com/en-gb/cpp/build/reference/zp-struct-member-alignment

Henry

If I do something like `echo '#include <wincred.h>' | gcc -E -dMD -P - | grep -i pack` I get this:

#undef _CRT_PACKING
#define _CRT_PACKING 8
#pragma pack(push,_CRT_PACKING)
#pragma pack(pop)

Before any of wincred.h gets defined, so the packing gets popped and it'll use the natural packing for the structs in wincred.h, which is why packrecords c works in my code. How does one know which header uses 8 bytes and which uses natural packing? (Apart from checking mingw like this, which to be fair has never let me down with winapi programming).

Henry

Op 2020-05-14 om 17:03 schreef Henry Vermaak via fpc-devel:

jwawindows.pas
     {$ALIGN 4}
{$ALIGN 4}
jwawinldap.pas
{$ALIGN ON}
jwawinsock2.pas
{$ALIGN 4}
jwaws2atm.pas
{$ALIGN ON}
jwaws2spi.pas
{$ALIGN OFF}
{$ALIGN ON}

But yeah, that looks bad.

Those are probably the exceptions then. But jwa* is delphi compat, so can't use $PUSH/$POP, so changing defaults is less useful, since it will be undone at the first exception

Marco van de Voort wrote

Those are probably the exceptions then. But jwa* is delphi compat, so can't use $PUSH/$POP, so changing defaults is less useful, since it will be undone at the first exception

What's even worse is that SetEntriesInAcl() was still crashing with {$packrecords c} because Jedi used packed records for EXPLICIT_ACCESS and TRUSTEE. Remove packed and it works fine (with {$packrecords c} that is).

So I'm going to conclude that most of this is unusable and cumbersome to fix on 64-bit. It probably warrants a compiler error or warning at least when any jwa* unit is compiled for 64-bit.

Henry