ごめんなさい。
先の私の回答には幾つか誤りがありました。ここでもう一度改めて説明しなおします。
Win64環境下で、C,C++でAPIのDLLをコンパイルする際に、CHOOSEFONTは８バイトパッキングなので、末尾パディングを含み、LOGFONTAは４バイトパッキングなので、は含まないということでしょうか？
アラインされることによって発生するパディングの有無およびその位置は、アライメントのサイズと各要素のメンバー定義によって決まります。（より詳しいルールを知りたい場合は、こちらを参照してみてください）
そしてその配置は通常、「既定のアライメント」に従ってアラインされることになります。ただし構造体によっては、「意図的に異なるアライメントでコンパイル」されているものも存在します。
既定のアライメントですが、これは構造体(あるいはユーザー定義型)に含まれる各メンバーの型のアライメントの中で、最大のアライメントに一致します。
.
LOGFONTA のメンバーでは、LONG, BYTE, CHAR という 3 つの型が使われていますが、このうち LONG 型が最大のアライメントを持っています。そのため、LOGFONTA 構造体の既定のアライメントは「4 バイト」です。そして 4 バイト単位でメンバーをパッキングしていった場合、隙間なく詰め込むことができるので、この構造体にはパディングが発生しません。
.
CHOOSEFONTA のメンバーでは、最大のアライメントとなるのがハンドル系(HWND, HDC, HINSTANCE)や LP何某系です。そのため本来であれば Win32 では 4 バイト、Win64 では 8 バイトが既定のアライメントにあたります。しかしながら、Windows SDK のヘッダーファイルにおいて
#if !defined(_WIN64)
#include <pshpack1.h> /* Assume byte packing throughout */
#endif
が指定されているため、Win32 においては、アライメントが「1 バイト」に変更されています。
Win32 では 1 バイトアライメントに変更されているため、CHOOSEFONTA にはパディングが発生しません。とはいえ、既定の 4 バイトのままであったとしても、「WORD nFontType;」の後に、わざわざ「WORD ___MISSING_ALIGNMENT__」を設けてあることもあり、追加のパディングは発生しません。そのため、VBA (32bit 版)から呼び出すときも、結果的にメンバーの位置調整は不要です。
一方 Win64 では既定の 8 バイトアライメントなので、先頭の「DWORD lStructSize;」とその次の「HWND hwndOwner;」の間に、4 バイトのパディングを設けてアラインされます。同様に、「LPARAM lCustData;」の直前に 4 バイトと、末尾「INT nSizeMax;」の直後に 4 バイトの、計 12 バイトのパディングが生まれます(これは C++ だけでなく VBA の場合にも当てはまります)。
ちなみに VBA のユーザー定義型は、メモリ上には「既定のアライメント」で配置される仕様ですが、ファイル入出力の場合は常に 1 バイトのアライメントとして扱われる仕様です(具体的には、Put #/Get # ステートメントでユーザー定義型を読み書きする場合です)。
.
注意が必要なのは、先述の SHFILEOPSTRUCT 構造体のケースのように、既定のアライメントだとパディングが発生するような定義になっていおり、かつ、既定のものよりも小さなアライメントが割り当てられているケースです。VBA
では既定のアライメントしか扱えないというのに、このケースでは、パディングのズレ以降にポインタ(LPVOID と PCSTR) があるため、このズレを自前で調整して呼び出さないと、クラッシュを誘発させる要因となってしまうのです。
.
とはいえ API で利用される構造体は、そもそも無駄なパディングが生まれないようなメンバー配置になっているものが多いはずです。なので、普段はパディングを意識する必要はありません。
一方、あえて異なるアライメントに調整されている構造体は、その多くが「既定のアライメントだとパディングが発生してしまう構造体」です。VBA 側へ移植する際に、『Len と LenB が異なる結果となるユーザー定義型』を見つけた場合は、注意が必要であるという事ですね。
なお、対象の構造体が求めるアライメントサイズを確認する場合、そのサイズがドキュメントに明記してあるわけではありませんので、C++ などで実際に呼び出して alignof や sizeof で確認してみないと分からないと思います。
.
最後に、VBA 側の 既定のアライメントを確認するために、いくつかの例を載せておきます。
Type U1 'これは 1 バイトのアライメントになる
A As Byte 'アライメント 1 バイト、サイズ 1 バイト
End Type
Type U2 'これも 1 バイトのアライメント
A As Byte 'サイズ 1 バイト、アライメント 1 バイト
B As Byte 'サイズ 1 バイト、アライメント 1 バイト
End Type
Type U3 'これも 1 バイトのアライメント
A As Byte 'サイズ 1 バイト、アライメント 1 バイト
B As Byte 'サイズ 1 バイト、アライメント 1 バイト
C As Byte 'サイズ 1 バイト、アライメント 1 バイト
End Type
Type U4 'これは 2 バイトのアライメント
A As Byte 'サイズ 1 バイト、アライメント 1 バイト
'(ここに 1 バイトのパディングが入る)
B As Integer 'サイズ 2 バイト、アライメント 2 バイト
End Type
Type U5 'これも 2 バイトのアライメント
A As Byte 'サイズ 1 バイト、アライメント 1 バイト
'(ここに 1 バイトのパディングが入る)
B As Integer 'サイズ 2 バイト、アライメント 2 バイト
C As Byte 'サイズ 1 バイト、アライメント 1 バイト
'(ここに 1 バイトのパディングが入る)
End Type
Type U6 'これは 4 バイトのアライメント
A As Byte 'アライメント 1 バイト、サイズ 1 バイト
'(ここに 3 バイトのパディングが入る)
B As Long 'サイズ 4 バイト、アライメント 4 バイト
End Type
Type U7 'これも 4 バイトのアライメント
A As Byte 'サイズ 1 バイト、アライメント 1 バイト
B As Byte 'サイズ 1 バイト、アライメント 1 バイト
'(ここに 2 バイトのパディングが入る)
C As Long 'サイズ 4 バイト、アライメント 4 バイト
End Type
Type U8 'これも 4 バイトのアライメント
A As Byte 'サイズ 1 バイト、アライメント 1 バイト
'(ここに 3 バイトのパディングが入る)
B As Long 'サイズ 4 バイト、アライメント 4 バイト
C As Byte 'サイズ 1 バイト、アライメント 1 バイト
'(ここに 3 バイトのパディングが入る)
End Type
Type U9 'これは Win32 では 4 バイト、Win64 では 8 バイトのアライメント
A As Byte 'サイズ 1 バイト、アライメント 1 バイト
'(ここに、Win32 なら 3 バイト、Win64 なら 7 バイトのパディングが入る)
B As Currency 'サイズ 8 バイト、アライメント Win32=4 バイト/Win64=8バイト
End Type
Type U0 'これも Win32 では 4 バイト、Win64 では 8 バイトのアライメント
A As Currency 'サイズ 8 バイト、アライメント Win32=4 バイト/Win64=8バイト
B As Byte 'サイズ 1 バイト、アライメント 1 バイト
'(ここに、Win32 なら 3 バイト、Win64 なら 7 バイトのパディングが入る)
End Type
ユーザー
定義型 |
Win32 |
Win64 |
アライ
メント |
Len |
LenB |
アライ
メント |
Len |
LenB |
| U1 |
1 |
1 |
1 |
1 |
1 |
1 |
| U2 |
1 |
2 |
2 |
1 |
2 |
2 |
| U3 |
1 |
3 |
3 |
1 |
3 |
3 |
| U4 |
2 |
3 |
4 |
2 |
3 |
4 |
| U5 |
2 |
4 |
6 |
2 |
4 |
6 |
| U6 |
4 |
5 |
8 |
4 |
5 |
8 |
| U7 |
4 |
6 |
8 |
4 |
6 |
8 |
| U8 |
4 |
6 |
12 |
4 |
6 |
12 |
| U9 |
8 |
9 |
12 |
8 |
9 |
16 |
| U0 |
8 |
9 |
12 |
8 |
9 |
16 |
