虽然经过修改，已经解决了大内存支持的问题（顺便也解决了MMIO吃掉内存的问题），然而，在32位环境无法解决的是，进程的地址空间的问题。因为架构的原因，现代的普通32bit操作系统上，每一个用户模式的应用程序可以寻址的通常只有2GB（有一个选项可以让其增大为3GB）。提供多于4GB容量的内存，每一个用户模式的应用程序可以寻址的容量仍然没有改变——尽管不同的应用程序都具有互相独立的的2GB寻址空间可以让大内存电脑同时运行多个不同的程序。

通常，64位的应用程序才可以使用超过2GB的内存；64位应用程序的寻址空间是4TB

　　通常的应用程序就受到了这个限制，例如，在使用如Maxthon这样的多页面浏览器打开70个图片页面的时候，程序的寻址空间就已经到达2GB了，这时虽然其工作集并不大，然而程序已经无法寻址更多的内存；继续打开新的页面只会让Maxthon崩溃。

　　为了让程序突破2GB寻址的限制，近代Windows NT核心提供了一个变通的方案：4GB内存调整优化技术，通过这个技术，可以将用户模式的寻址空间扩大至3GB，这样核心寻址空间便被限制为1GB了，需要超大内存容量的应用程序可以从这个特性中获得性能改善，如SQL Server数据库这种类型。要使用这个4GB内存优化技术，用户需要在Windows Server操作系统的启动参数中加入/3GB开关。这个特性同时需要操作系统打开DEP（数据执行保护，其实/3GB开关需要的是PAE的支持）。

　　对于一个用户进程来说，默认的2GB可能已经足够，然而对于操作系统核心来说——所有的内核模式程序包括内核、驱动程序、系统缓存等都共享着相同的2GB空间（或者1GB；从这点上看，Windows已经不怎么具有微内核的样子了，为了性能，Windows将许多本应该放在用户模式的系统服务都放进了内核），在一个大系统上很容易受到限制。如上图这样，系统的System Cache总不会超过2GB（还要加上核心内存的占用），这样Superfetch也就无法发挥最大的作用。