assembly - windows进程内存布局

Question

所以我正在玩 Olly 调试器，嗅探我能找到的关于 Windows 的信息，然后我按下了 M 按钮，它弹出了内存映射窗口。所以我用谷歌搜索了一些关于这个主题的文章，我发现我实际上可以写入 64K 以上的地址，我尝试过并且很好..为什么它不起作用。关于那些较低的 2GB 空间:

• 为什么会有这些差距？例如，有 0x10000-0x1FFFF R/Wable 空间，然后有 128K 没有任何空间，然后有一些只是可读空间。我的意思是这已经分页正确了，所以过去是否有类似物理空间的东西并不重要(更不用说 0x20000-0x40000 应该完全可以读/写)，为什么有人决定不这样做如此随机地使用一些地址空间？我很可能只是感到困惑，因为在 olly 调试器的内存映射中，许多行在列显示“包含”的地方留空。是否有一些引用，我可以根据 olly 的内存映射来查找哪些空间有什么用途，因此是或不是这样分页的？

• 假设我真的不会搞砸内存管理，那么使用较低的内存而不是堆为 Windows 编写程序是否可以，或者我会遇到一些问题吗？

感谢您阅读这个问题。

编辑

啊here我们选择 0x10000 处的内容，这也可能是该页面可写的原因。

Answer 1

您似乎没有提出有针对性的问题，因此很难提供有值(value)的答案。但是，您似乎暗示了这个问题Windows如何映射用户空间内存？

首先，低虚拟内存空间(从 0 到 64K 或更多)未分配，以捕获基于 NULL 的指针取消引用。这些是我们希望立即了解的常见编程错误。如果发生这种情况，程序几乎肯定会终止。如果不映射此空间，则会出现 Windows 中的 SEGFAULT 等效项。非常有用。

通常，接下来分配代码和常量空间。一旦程序开始运行，通常不需要更改该空间，因此将其设置为只读，并将其中的一部分标记为可执行——通常是第一部分，可以是空间的 99%。如果存在共享代码库，则这些代码库会映射到主代码之后(通常)，通常具有较小的间隙，以便库代码段页对齐(可能是 4K，可能是 64K 或更大)，以实现高效的内存管理寄存器使用。很少需要节省虚拟内存空间。

之后是数据空间。那可以是已初始化的内存，也可以是未初始化的。这一切都必须是可读写的。并且它需要在其上方保留空间，以便它可以随着堆空间的增长而增长。

数据空间之上就是堆栈空间。它必须是可读写的，并且下面有空间，这样它才能增长。所有现代 CPU 堆栈都朝着低内存方向发展。

堆栈之上是系统空间。

如果进程请求访问共享内存(与其他进程)，则映射窗口的大小决定了它在内存映射中的位置。映射得太靠近堆增长的位置是一个问题，太靠近潜在的堆栈增长也是一个问题。幸运的是，相当简单的放置算法可以为绝大多数程序解决这个问题。只要想一想各种需求，您就可能明白操作系统为什么要这样做。