在 Windows 中，进程希望看到的总空间在 CS、DS 和 SS 寄存器中是相同的。Windows 将可执行文件以及任何 DLL、打开的文件、分配的内存段等放入此地址范围，并且您将看到相同的内存 - 以及相同的内容 - 无论您是否访问 cs:[something] , ds:[something] 或 ss:[something]*。

在 32 位系统上，这个“大空间”中的可达内存为 4 GB。

FS不同；它是正常地址空间之外的一个单独的内存部分。您无法使用任一普通寄存器访问该内存。它的大小只有几个字节 - 例如，您无法访问 FS:[100000h]，因为 PEB 并没有那么大。

回到线性 4 GB 空间：4 GB“可达”的事实来自 32 位指针 (2^32)；但这并不意味着该范围内的每个地址实际上都映射到物理内存。每当 Windows 需要一块内存时，它就会在该空间中选择一个地址，将物理内存映射到它，并使用该内存。例如，当一个可执行文件被加载时，windows 总是会**将它加载到400000h. 这就是为什么你的程序开始于401000h- 你的入口点1000h 是相对于加载地址，而不是 0。或者，当 Windows 加载一个 DLL 时，它将80000000以为 ASLR），并使用该地址。如果您的 DLL 的入口点在1000h，并在 加载63000000h，则执行将从 开始63001000h。

您无法访问 cs:[0] 或 ds:[0] 的事实是故意的 - Windows 不会将任何内容映射到地址空间的第一个字节以使您的程序崩溃（技术上：抛出执行）如果它尝试通过 NULL 指针访问内存。这也是可执行文件在内存中加载更高的原因，您不希望空指针访问意外成功。

接下来要考虑的是windows如何加载 PE 文件 - 而不是解析文件，并且只将区域复制到实际使用的内存中，它只是将整个文件中的内容拖到起始地址***。这意味着，PE 标头被加载到加载地址。您看到的伪代码只是 PE 标头的一部分，恰好400h位于 PE 文件中的偏移处。

为了熟悉“大”cs/ds/ss 段的内存布局，我推荐vmmap使用 sysinternals 集合中的工具；将它附加到一些正在运行的进程并检查它们的内存映射。与任何理论解释相比，细节可能会变得更加清晰。

(*) 但是，根据访问权限，您可能不允许写入该空间中映射到代码的部分，或执行映射到数据的部分。

(**) 对于总是有点模糊的定义，细节现在并不重要

(***) 从技术上讲，它内存映射文件并依赖分页子系统从磁盘读取它，但同样，现在这并不重要。

如果使用链接器开关 /ALIGN:16，可执行代码可能从 base+0x2b0 开始

编辑

死代码可能是一个被编译和链接但从未调用的函数，如果你像这样修改上面的 src 并编译第一次调用 messagebox 将在二进制文件中可用但没有人会引用它

#include <windows.h>
#pragma comment(lib , "user32.lib")
void deadcode(void)
{
  MessageBox(0,"iam dead","yep deady dead deady dead",0);
}
void main (void) {
  MessageBoxA(0,"disme to see me low",
  "using align 16 and merge sections iam slim(e)y",
  0);
} 

这是从未被引用但仍然存在的死代码

>cdb -c "x msgbox!*;q" msgbox.exe | grep main
004002d0 msgbox!main (void)

>cdb -c "u msgbox+2d0-20;q" msgbox.exe | grep -A 4 55
004002b0 55              push    ebp
004002b1 8bec            mov     ebp,esp
004002b3 6a00            push    0
004002b5 680c024000      push    offset msgbox!⌂USER32_NULL_THUNK_DATA+0x28 (004
0020c)
004002ba 6828024000      push    offset msgbox!⌂USER32_NULL_THUNK_DATA+0x44 (004
00228)

>cdb -c "da msgbox+20c;q" msgbox.exe | grep dead
0040020c  "yep deady dead deady dead"