Assembly windows进程内存布局

所以我在玩Olly debugger，嗅探我能找到的关于windows的信息，按下M按钮，它弹出了内存映射窗口。所以我在谷歌上搜索了一些关于这个主题的文章，我发现我实际上可以写64K以上的地址，我试着写得很好。。为什么它不起作用。关于较低2GB的空间：

• 为什么会有这些差距？例如，有0x10000-0x1fff R/Wable空间，然后有128K空，然后有一些只是可读的空间。我的意思是，这已经被正确地分页了，所以过去是否有类似物理空间的东西并不重要（不提0x20000-0x40000对r/w to来说应该是完全可以的），为什么会有人决定不随机使用某些地址空间？ 很可能我只是感到困惑，因为在olly debugger的内存映射中，很多行在列显示“Contains”的地方是空的。是否有一些参考，我可以放在奥利的记忆地图上，找出什么空间有什么用途，是这样还是不这样分页

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

谢谢你阅读这个问题

编辑

---

啊，我们使用的是0x10000，这也可能是该页面可写的原因。

并非所有内存都可供应用程序使用。例如，某些类型的硬件需要内存，因此系统（BIOS或OS）将分配一块物理内存，并将其留给硬件自行管理。该内存可能无法直接读取（或写入），因为执行此类操作会影响硬件。硬件本身可能对它可以使用的内存范围有自己的限制

如果您在Windows中，您不能写入任意内存位置-操作系统不允许您（至少在用户模式下）并且无论如何都会分页内存，因此您认为正在查看的地址（虚拟地址）与实际物理内存地址不匹配

---

一般来说，您应该只对操作系统请求和分配给您的内存进行读写。

您似乎没有重点问题，因此很难提供有价值的答案。然而，您似乎暗示了这样一个问题：Windows如何映射用户空间内存

首先，从零到64K或更多的低虚拟内存空间未分配，以捕获基于NULL的指针解引用。这些是我们想要立即了解的常见编程错误。如果出现这种情况，程序几乎肯定会终止。如果不映射此空间，则会出现与Windows相当的SEGFAULT。非常有用

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

之后是数据空间。可以初始化内存，也可以不初始化。这一切都必须是读写的。它需要在其上方保留空间，以便能够为堆空间的增长而增长

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

堆栈上方是系统空间

---

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

。。这就是我想做的：）关于你的最后一个问题。。。我怀疑你能用受保护的内存写东西。它的位置取决于操作系统。因此，请阅读更多有关制作操作系统的内容，然后阅读ab windows如何映射其内存（我假设win，因为您提到了Olly），将地址0x10000加载到指针中，然后将值写入0x20000并没有引发任何错误。总之，“windows如何映射其内存”是我无法找到的内容，也是我在这里询问的原因。我是说有关于Windows虚拟地址空间的文章，但就我所发现的而言，它总是关于用户和系统部分的划分，以及每个进程如何巧妙地具有相同的内存布局。@adelphus它是Windows 7是的，它可能是分页内存，这就是为什么我不明白为什么地图是这样的，而不是连续的虚拟内存块。@Study\u Duty可能是碎片；也许MS决定在他们的算法中这样做