为何IMAGE_DOS_HEADER中e_lfanew字段类型在不同winnt.h中为LONG或DWORD？

首先得明确：不管是LONG还是DWORD，在Win32/Win64平台下，这俩类型的内存大小都是4字节（32位），所以不管头文件里写的是哪种，实际编译后字段的内存布局完全一致，不会导致兼容性问题。

为什么会有DWORD和LONG的区别？ #

1. 历史遗留与Win9x的关联
   确实，早期Win9x时代的SDK里，e_lfanew的定义是DWORD，这是因为当时的DOS和16位Windows体系里，偏移量常用无符号的32位值表示。NT系列的早期SDK也延续了这个定义，但微软后来在更新的SDK（比如Win11版本）里把它改成了LONG，本质是语义上的规范调整，不是功能上的变更。

2. 微软的类型语义规范
   在Windows的类型体系里，LONG通常用于表示有符号的偏移或数值，DWORD则是无符号的32位整数。e_lfanew是DOS头指向PE文件NT头的偏移量，本身是正的，但微软调整类型是为了和PE文件结构中其他类似偏移字段的类型保持统一，或是适配内部加载逻辑中使用的参数类型——核心还是两者内存大小一致，代码不会因为这个类型变更出问题。

为什么网上资料和实际代码不一致？ #

• 老文档未更新：很多技术博客、教程基于WinXP甚至更早的SDK编写，当时的定义还是DWORD，这些内容没有随着微软SDK的更新修正，导致信息滞后。
• 不同工具链的兼容策略：mingw-w64这类第三方工具链，旧版本可能为了兼容更多老代码或保持历史兼容性，保留了DWORD的定义；而微软官方SDK则随着系统迭代做了语义调整，因此出现差异。
• 类型兼容的隐蔽性：因为LONG和DWORD的内存大小完全一样，即使代码里混用两种类型定义，编译运行也不会出错，所以很多人没注意到这个变更，进一步导致了资料混乱。

内容的提问来源于stack exchange，提问作者Jet Tang