我的理解（来自 Wikipedia）是 x64 指令集支持从长模式执行 16 位保护模式代码，但无法在不切换出长模式的情况下执行实模式代码，因为长模式缺少虚拟 8086 模式。因此，实模式 DOS 应用程序无法在没有软件模拟或动态转换的情况下在 Win64 中运行，这是有道理的。但是，为什么在 Win16 保护模式应用程序的支持似乎（至少乍一看）是合理可行且包含在 Win32 的较新版本中时，却排除了对它们的支持？这仅仅是因为需求不够高，不足以证明实施成本是合理的（并且 win32 版本已经实施），还是有充分的技术原因？
答案1
我认为没有任何实际的 Win16 保护模式应用程序。我知道 Windows/286 及更高版本在保护模式下运行（Microsoft 称之为“标准模式”或“增强模式”），但这些应用程序在技术上是实模式应用程序。
我记得曾经读到过，Windows 团队竟然搞清楚了如何在受保护模式操作系统下运行实模式代码，这让微软大吃一惊。但在长模式下运行实模式代码的类似解决方案可能并不存在。
所以问题实际上归结为 a) 为什么不切换到保护模式（或实模式）来运行 Win16 应用程序以及 b) 为什么不包含一个模拟器（就像在其他非 x86 NT 平台上一样）。
我认为，a) 的答案是显而易见的，因为在长模式和其他模式之间切换并不是 CPU 在没有重新启动的情况下真正支持的功能。OS/2 1.x 在保护模式和实模式方面存在同样的问题，并且只提供了一个非常不优雅的解决方案。
b) 的答案更难，但我认为这取决于微软基于以下三点做出的决定（我喜欢列表）：
很少有人仍然运行 16 位应用程序。
那些可以运行 32 位 Windows 的人可以运行它们。
第三方产品可以覆盖剩余的市场。
确实，有几种在 64 位 Windows 下运行 32 位 Windows（以及 16 位应用程序）的解决方案，包括微软自己的虚拟 PC。
总而言之，这只是一个决定，停止支持与（微软认为的）旧平台的兼容性，有点像在 Windows XP 中删除 16 位 OS/2 兼容性。（那些是 16 位保护模式应用程序。）
答案2
@AndrewJBrehm 的回答很好，但我想补充两点：删除 16 位支持使 64 位产品的维护更加容易和更安全。想象一下多年来为 16 位子系统建立的测试用例数量。每次进行更改时，您都必须确保不会发生任何损坏。更多的子系统，尤其是（相对）很少使用的子系统，如 16 位子系统，是攻击者的良好目标。