为什么64位Windows上的本机长基元的大小只有4个字节？

Question

有人请告诉我这有什么意义,以及如何让它停止？说真的,我疯了还是64位Windows长型只有4个字节？这有什么用呢？我认为本机长原始大小应该与本机寄存器大小相同.

[32-bit Linux]

me@u32:~$ ./sizes32
sizeof(char):      1
sizeof(short):     2
sizeof(int):       4
sizeof(long):      4
sizeof(long long): 8

[64-bit Linux]

me@u64:~$ ./sizes64
sizeof(char):      1
sizeof(short):     2
sizeof(int):       4
sizeof(long):      8
sizeof(long long): 8

[32-bit Windows]

C:\Users\me\Downloads>sizes32.exe
sizeof(char):      1
sizeof(short):     2
sizeof(int):       4
sizeof(long):      4
sizeof(long long): 8

[64-bit Windows]

C:\Users\me\Downloads>sizes64.exe
sizeof(char):      1
sizeof(short):     2
sizeof(int):       4
sizeof(long):      4
sizeof(long long): 8

Answer 1

long必须至少为 32 位，至少与 一样大int且不大于long long. 就是这样。时期。

Answer 2

向后兼容!

窗户来自16位平台,sizeof(long) == 4并广泛使用的类型,如LONG,DWORD...并改变它将使大量的代码崩溃或无法编译

在第9频道,成员Beer28写道,"我无法想象类型宽度发生变化的节目存在太多问题." 我从中得到了一个很好的笑声并记下了在Win64数据模型上写一个条目.

Win64团队选择了LLP64数据模型,其中所有整数类型保持32位值,只有指针扩展为64位值.为什么？

除了在该网页上给出的原因之外,另一个原因是这样做可以避免破坏持久性格式.例如,位图文件的部分标题数据由以下结构定义:

typedef struct tagBITMAPINFOHEADER {
        DWORD      biSize;
        LONG       biWidth;
        LONG       biHeight;
        WORD       biPlanes;
        WORD       biBitCount;
        DWORD      biCompression;
        DWORD      biSizeImage;
        LONG       biXPelsPerMeter;
        LONG       biYPelsPerMeter;
        DWORD      biClrUsed;
        DWORD      biClrImportant;
} BITMAPINFOHEADER, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;

如果LONG从32位值扩展到64位值,则64位程序无法使用此结构来解析位图文件.

为什么Win64团队选择LLP64模型？