为什么一个*什么都不*的 EXE 文件包含这么多虚拟零字节？
我编译了一个完全不执行任何操作的 C 文件（只是返回一个 main...甚至没有打印“Hello, world”），并且我使用各种编译器（MinGW GCC、Visual C++、Windows DDK 等）。它们全部与 C 运行时链接，这是标准的。
但我不明白的是：当我在十六进制编辑器（或反汇编器）中打开文件时，为什么我看到 16 KB 的几乎一半只是 0x00 字节或 0xCC 字节的巨大部分？这对我来说似乎相当荒谬......有什么办法可以防止这些发生吗？他们首先为什么会在那里？
谢谢你！
I've compiled a C file that does absolutely nothing (just a main that returns... not even a "Hello, world" gets printed), and I've compiled it with various compilers (MinGW GCC, Visual C++, Windows DDK, etc.). All of them link with the C runtime, which is standard.
But what I don't get is: When I open up the file in a hex editor (or a disassembler), why do I see that almost half of the 16 KB is just huge sections of either 0x00 bytes or 0xCC bytes? It seems rather ridiculous to me... is there any way to prevent these from occurring? And why are they there in the first place?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
可执行文件通常包含一个代码段和至少一个数据段。我猜每一个都有一个标准的最小尺寸，可能是 8K。未使用的空间用零填充。另请注意，用更高级别（比汇编）语言编写的 EXE 除了直接翻译您自己的代码和数据之外还包含一些额外的内容：
main()，然后在退出main()后清理）尽管如此，由于可执行文件通常应该做一些事情（即它们的代码和数据段确实包含有用的东西），并且存储很便宜，因此默认情况下没有人针对您的情况进行优化:-)
但是，我相信大多数编译器都有您可以使用命令行参数强制它们优化空间 - 您可能需要检查该设置的结果。
以下是有关 EXE 文件格式的更多详细信息。
Executables in general contain a code segment and at least one data segment. I guess each of these has a standard minimum size, which may be 8K. And unused space is filled up with zeros. Note also that an EXE written in a higher level (than assembly) language contains some extra stuff on top of the direct translation of your own code and data:
main(), then cleans up after exiting frommain())Still, since executables are usually supposed to do something (i.e. their code and data segment(s) do contain useful stuff), and storage is cheap, by default noone optimizes for your case :-)
However, I believe most of the compilers have command line parameters with which you can force them to optimize for space - you may want to check the results with that setting.
Here is more details on the EXE file formats.
事实证明，我应该能够事先猜到这一点......答案是调试符号和代码；这些占据了大部分空间。不使用 /DEBUG 和 /PDB 进行编译（我总是默认这样做）将 13 K 减少到 3 K。
As it turns out, I should've been able to guess this beforehand... the answer was the debug symbols and code; those were taking up most of the space. Not compiling with /DEBUG and /PDB (which I always do by default) reduced the 13 K down to 3 K.