а как быть со вторым вопросом, не подскажите ?

повтори/перефразируй

так, есть структура

typedef struct tagPROCESSENTRY32 {
  DWORD     dwSize;
  DWORD     cntUsage;
  DWORD     th32ProcessID;
  ULONG_PTR th32DefaultHeapID;
  DWORD     th32ModuleID;
  DWORD     cntThreads;
  DWORD     th32ParentProcessID;
  LONG      pcPriClassBase;
  DWORD     dwFlags;
  CHAR      szExeFile[MAX_PATH];
} PROCESSENTRY32;

используется для снапшота процессов в x32, она так же работает в x64

из мсд видно, что поле ULONG_PTR это указатель, соответственно на x64 это будет dq, остальные поля стсруктуры dd и 1 char, вот как это совмещают не разрушив структуры и сохранив выравнивание ?

на си можно в принципе написать, посмотреть попробывать как компилятор справляется с этм, но это очень уж кривой путь )

пишу в fasm

не 1 чар, а массив чаров рпный 512 байт, или сколько там maxoath состпвляет

да, я это имел ввиду, суть это не меняет

выравнивание ломается же не доходя до массива еще, там где dq, тоесть не вырванивание а структура полей

получается все адреса элементов структуры кратны 4б

sizeof сделай и сравнт размер структуры

ну да кратны, но вызов апи то будет считать что по адресу, где у нас резервируются байту уже идет другое поле

если различается с тем что ты в ручную посчитал, то значит фасм макросами делает выраанивание

составь минимальный пример в подтверждении своей теории

нет ну выравнивание с этим понятно, с кратностью 4 dd и 8 dq, тут разобрался вроде, а что делать с тем, что там где у нас выравнивание, тоесть фактически пустое место, 4 пустых байта, вызов винапи же не знает что это наше выравнивание, он записывает в эти 4 байта ULONG_PTR th32DefaultHeapID, и тем самым структура структуры так сказать нарушается )) На практике уже пробывал, это выглядит так - когда обращаюсь к массиву видно в отладчике что обращение идет уже по не правильному смещению

ну тоесть короче говоря, размер структуры с выравнивание не совпадает с размером этой структуры котрой пользуется винапи, из за выравнивани и добавления 4 лишних байт что бы поставить dq на свое место

в целом если не вдаваться в конкретный случай, вопрос можно сформулировать так - как совмещаются в одной структуре dd и dq данные, вообще это нормально ? апи вызов был написан под x32 соответственно и структура для него на x32 рассчитана, но его используют и в x64.
Или это всё скрещения ужа с ежом

сколько байт ULONG_PTR?

зависет от разрядности ось, 8 в 64, это же указатель