我想在它被历史遗忘之前帮助保存这个设置存在的原因。
简短版本：损坏的 DOS 扩展程序使用 16 位有符号整数。任何大于 32,768 字节 (32 MB) 的内容都会导致它们失败。
Thomas R. Nicely 在 2007 年发表了一篇文章，指出了问题所在：
Windows Vista 将非 Win32 应用程序的内存限制为 32 MB （存档）
然后有一篇 2010 年 usenet 的帖子提醒我们，操作系统限制了 DPMI 可用的内存量：
我最近在 Windows Vista 的 DPMI 服务器上看到了 Thomas R. Nicely 的 WWW 页面。这很困惑。（这些人对 M. Nicely 的页面问题有一些非常明智的说法。）难怪，如果这是你向 M. Nicely 解释事情的方式，就像 xe 声称的那样。（-：
事实上，这个 DPMI 服务器限制是另一个例子。M. 很好地将其描述为某种针对 gcc 的神秘阴谋。事实上，正如 M. bwakaz 所指出的，它可以简单地防御基于 DPMI 的扩展 DOS 应用程序所做的所有愚蠢和破坏的事情，例如分配程序启动时可用的所有内存，因为他们写得不好。M. bwakaz 指出Raymond Chen 的一篇文章，任何想要理解这一点的人都应该阅读。
你提到的这个DpmiLimit设置其实并不是什么新鲜事。它在 Windows NT 6
上根本没有记录。近二十年来，OS/2 VDM 的 DPMI 内存限制设置已记录在案。设置是DPMI_MEMORY_LIMIT。您可以在 Usenet 和 WWW 上阅读数百个关于此的讨论，这些讨论可以追溯到 1994 年左右，以及上下调整它的原因。在 OS/2 系统上，可以打开 VDM 设置笔记本，并获得描述设置的在线帮助。
Raymond Chen 指出 DOS 游戏是滥用 DPMI 的罪魁祸首，有一个完整的关于在 OS/2 下运行 DOS 游戏的常见问题解答，DPMI_MEMORY_LIMIT其中列出了让这些游戏很好玩的各种不同
（和其他）设置操作系统而不是不必要地占用内存，因为 VDM 中的 DPMI 服务器会允许它们这样做。
同样，NTVDM 一点也不“奇怪”。它实现了一个设置和一个限制，这与虚拟 DOS 机器中的课程相当。即使是 32MiB 的默认值也不稀奇。OS/2 VDM 中的默认值
DPMI_MEMORY_LIMIT是（在最新版本的 OS/2 中，如果有记忆的话）64MiB。如果您一直阅读 Raymond Chen 的文章，甚至可以解释为什么这些值是默认值：这是为了应对损坏的扩展 DOS 程序，这些程序使用 16 位整数以 KiB 为单位测量可用 DPMI 内存。（NTVDM 的默认值采用有符号的 16 位整数。OS/2 的 VDM 的默认值采用无符号的 16 位整数。）
所有这些事情——无论是从 VDM 内部进入 VM 监视器，还是 DPMI 服务器限制以控制写得不好的 DOS 程序——都不是 NTVDM 是“奇怪”或不寻常的，或者是微软对那些认为编译的人的秘密阴谋使用 gcc 表示正在编译扩展的 DOS 程序。它们是 VDM 的简单长期实践，以及可以追溯到几十年前的虚拟机技术的常规材料。