我的理解（来自维基百科）是指x64指令集支持从长模式执行16位保护模式代码，但由于长模式缺乏虚拟8086模式，不能执行实模式代码而不能切换到长模式。 因此，有理由认为，实模式DOS应用程序不能运行在Win64的W / O软件模拟或dynamic翻译。 然而，为什么当支持Win16保护模式的应用程序似乎（至less乍一看）是合理的可执行的，并包含在新的Win32版本？ 这只是一个需求不足以certificate实施成本（而win32版本已经实现）的问题，还是有一个很好的技术原因？
我不认为有任何实际的Win16保护模式的应用程序。 我知道Windows / 286及以上运行在保护模式（微软称为“标准模式”或“增强模式”），但这些应用程序是技术上的实模式应用程序。
我记得读到微软惊喜地发现，Windows团队想出了如何在保护模式下运行实模式代码。 但是，在长模式下运行实模式代码的类似解决scheme可能不存在。
所以这个问题真的归结为a）为什么不切换到保护模式（或实模式）来运行Win16应用程序和b）为什么不包括模拟器（如在其他非x86 NT平台上）。
对于a）的回答很明显，我认为，因为在长时间模式和其他模式之间切换不是没有重新启动的CPU支持。 OS / 2 1.x在保护模式和实模式方面有同样的问题，只能提供一个非常不好的解决scheme。
对b）的回答更加困难，但我认为这归结于微软基于这三点（我爱列表）的决定：
很less有人仍然运行16位应用程序。
那些谁可以运行32位Windows来运行它们。
第三方产品可以覆盖剩余的市场。
事实上，在64位Windows下运行32位Windows（以及16位应用程序）的解决scheme，其中包括微软自己的Virtual PC。
总而言之，这只是一个决定，停止支持与微软认为的传统平台的兼容性，就像在Windows XP中删除16位OS / 2兼容性一样。 （这些是16位保护模式的应用程序。）
@ AndrewJBrehm的答案是好的，但我要补充的两点是，删除16位支持使得64位产品的维护更容易和更安全。 想象一下这些年来为16位子系统build立的testing用例的数量。 任何时候你做出改变，你都必须确保没有任何事情被破坏。 更多的子系统，特别是（相对）较less使用的子系统，如16位子系统，是攻击者的好目标。