自上篇“程序中的内存分配浅谈”贴出后，很多网友都跟我探讨过这方面的问题，也有不少大侠悉心指出其中谬误，在此halk表示衷心感谢！这篇文章可以说是继续上一篇的话题来的，同时也是我自己不断深入学习的心得。虽因个人水平有限错误不可避免，但还是想写出来，希望能够与大家共同探讨！
引子：勘误
上篇中存在若干错误，此处予以纠正。
1． 程序退出后，windows系统将收回所有分配的物理存储器，并释放句柄表，因而进程中new的内存空间不会永久存在，而是随进程而消亡。感谢GUOJIAN朋友指出此错误！
2． 有关字对齐的约定，在C程序编译的时候有一个选项可以控制的。对于X86来说，CPU本身会对非对齐的字进行对齐处理；而Alpha系列CPU则不支持此特性，如果需要的时候必须用软件实现，会显著影响处理速度。因而在通常情况下还是遵照默认选项，选择字对齐为好。
三．进程空间
Win32的可执行文件在加载后，系统将为它建立一个它自己的虚拟内存空间，即进程空间，其容量达4G（64位系统中将更大，但我想64位的程序应该不叫做Win32程序了吧？）。这4G的空间划分为了几个区域，对于win98和win2000是不尽相同的。
Window2000 Windows98
NULL指针分配分区 0x00000000~0x0000ffff 0x00000000~0x00000fff
MS-DOS/Win16兼容分区 无 0x00001000~0x003fffff
用户分区 0x00010000~0x7ffeffff 0x00400000~0x7fffffff
禁止访问分区（64K） 0x7fff0000~0x7fffffff 无
共享（MMF）分区 无 0x80000000~0xbfffffff
内核方式分区 0x80000000~0xffffffff 0xc0000000~0xffffffff
(上表资料来自：《Windows核心编程》)
NULL指针分区是NULL指针的地址范围。对这个区域的读写企图都将引发访问违规。
DOS/WIN16分区是98中专门用于16位的DOS和windows程序运行的空间，所有的16位程序将共享这个4M的空间。Win2000中不存在这个分区，16位程序也会拥有自己独立的虚拟地址空间。有的文章中称win2000中不能运行16位程序，是不确切的。
用户分区是进程的私有领域，Win2000中，程序的可执行代码和其它用户模块均加载在这里，内存映射文件也会加载在这里。Win98中的系统共享DLL和内存映射文件则加载在共享分区中。
禁止访问分区只有在win2000中有。这个分区是用户分区和内核分区之间的一个隔离带，目的是为了防止用户程序违规访问内核分区。
MMF分区只有win98中有，所有的内存映射文件和系统共享DLL将加载在这个地址。而2000中则将其加载到用户分区。
内核方式分区对用户的程序来说是禁止访问的，操作系统的代码与此。内核对象是否也驻留在此？我认为应该是的，因为应用程序不能直接访问内核对象。但是关于这点我没找到有关的叙述，不知哪位大侠有确切的依据？另外要说明的是，win98中对于内核分区本也应该提供保护的，但遗憾的是并没有做到，因而98中程序可以访问内核分区的地址空间。
四．进程空间中的内存分配
可能很多初学的朋友会疑惑：每个进程4G空间？那我们要多大的内存才成！
事实上，我们给予每个进程的4G空间都是虚拟的，或者说虚幻的，在没有对一段空间定义之前，它根本只有逻辑意义，实际上并不存在。
我们可以根据情况把一段虚拟空间指定为“保留”的或者“提交”的，这样这段地址空间就不能再做它用，直到被释放。二者的区别是“提交”的空间将分配给物理存储器（RAM、磁盘页文件），而“保留”的则不分配。事实上在2000中，“提交”的空间也不是马上分配给物理存储器的，而是在第一次访问的时候才分配。
进程中每个线程都有自己的堆栈，这是一段线程创建时保留下的地址区域。我们的“栈内存”即在此。至于“堆”内存，我个人认为在未用new定义时，堆应该就是未“保留”未“提交”的自由空间，new的功能是在这些自由空间中保留（并提交？）出一个地址范围。
