64 位 Windows 上 PE 文件的最大大小是多少？
在我看来它总是 4GB，因为它使用相同大小的数据类型（A DWORD）？ SizeOfImage 的 DWORD 不总是 32 位吗？或者我对这个限制有什么误解？
回答
4GB 确实似乎是所有可移植可执行文件（32 位和 64 位 PE+）的硬限制。
It seems to me it's always going to be 4GB, because it uses the same size datatype (A DWORD)? Isn't a DWORD for the SizeOfImage always going to be 32-bits? Or am I mistaken about this limitation?
Answer
4GB does indeed to seem to be the hard limit of ALL Portable Executable's (32-bit and 64-bit PE+).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据 规范 它是 32 位 < em>PE32+ 图像的无符号值，就像 PE32 图像一样。
但是，在我在 Windows 7 SP1 Home Premium x64 上对 32 位和 64 位应用程序（PE32/PE32+ 文件）进行测试时，两者的最大文件大小在 1.8-1.85GB 之间。
我通过使用 Visual Studio 创建一个非常基本的 C 可执行文件（32 位约为 8K，64 位约为 9K）进行测试，并向 PE 标头添加一个空代码部分，直到 Windows 不再加载它，然后二进制搜索极限。使用 vmmap 查看进程表明，几乎所有前 2GB 地址空间都是映像（包括任何随后加载的 DLL，例如 kernel32.dll）。对于我来说，32 位和 64 位进程的限制是相同的。 64 位进程确实在其 NT 标头的文件标头部分中设置了标志，表明它可以处理大于 2GB 的地址。它还可以为超过 2GB 限制的非图像部分分配内存。
看起来图像需要完全适合进程的 2GB VA 空间，这意味着加载器有效地将 SizeOfImage 视为有符号的 32 位整数。
According to the spec it is 32-bit unsigned value for a PE32+ image just like a PE32 image.
However, in my testing with both 32-bit and 64-bit applications (PE32/PE32+ files) on Windows 7 SP1 Home Premium x64, the maximum file size for either is between 1.8-1.85GB.
I tested by creating a very basic C executable with Visual Studio (~8K for 32-bit and 9K for 64-bit) and the added an empty code section to the PE header until Windows would no longer load it, and then binary searched for the limit. Looking at the process with vmmap showed that almost all of the entire first 2GB of address space were the image (including any subsequently loaded DLLs such as kernel32.dll). The limit was the same for me with both 32 and 64-bit processes. The 64-bit process did have the flag set in it's NT Header's File Header's section stating that it could handle addresses >2GB. It also could allocate memory for non-image sections above the 2GB limit.
It seems like the image is required to fit in it's entirety in the lower 2GB of VA space for the process, which means the SizeOfImage is being treated a signed 32-bit integer by the loader effectively.
根据 COFF/PE32规范，有效 PE32+（64 位/(PE+) 文件的图像大小为 4 字节无符号值。
According to the COFF/PE32 spec, the image size for a valid PE32+ (64 bit/(PE+) file is a 4 byte unsigned value.
PE 标头中的 ImageSize 字段与 PE 文件在磁盘上的文件大小很大程度上无关。 ImageSize 是加载图像的内存大小，即所有部分的大小（每个部分四舍五入到SectionAlignment 边界）+ PE 标头的大小（在下一个标头字段 SizeOfHeaders 中给出）。该值不能> PE32 或 PE32+ 为 2GB，因为 a) 规范如此规定，b) 规范中存在 31 位 RVA，例如在导入查找表中。 RVA 是作为距内存基地址的偏移量给出的内存引用。
虽然那是在记忆中。磁盘上的文件可以包含未加载到内存中的数据（例如调试数据、证书数据）。 PE 规范中的文件指针字段是 32 位无符号值。因此，根据规范，PE文件的理论最大大小为 4GB。
这是根据规范。 PE 规范之外可能存在文件系统、加载程序、操作系统限制，从而进一步降低最大值。
The ImageSize field in the PE headers is largely unrelated to the file size on-disk of the PE file. ImageSize is the in-memory size of the loaded image i.e. the size of all sections (each rounded to the SectionAlignment boundary) + size of the PE headers (given in the next header field, SizeOfHeaders). This value cannot be > 2GB for either PE32 or PE32+ because a) the spec says so and b) there exist 31-bit RVAs in the spec, e.g. in the import lookup table. RVAs are memory references given as offsets from the in-memory base address.
That's in memory though. The file on disk can contain data that is not loaded into memory (e.g. debug data, cert data). File pointer fields in the PE spec are 32-bit unsigned values. So the theoretical maximum size of a PE file according to the spec is 4GB.
That's according to the spec. There may be file-system, loader, OS limits outside of the PE spec that reduce the maximum further.