私の理解(ウィキペディアから)は、x64命令セットはロングモードからの16ビットプロテクトモードコードの実行をサポートしていますが、ロングモードには仮想8086モードがないため、ロングモードから切り替えずにリアルモードコードを実行することはできません。したがって、ソフトウェアエミュレーションまたは動的変換なしでWin64でリアルモードDOSアプリを実行できないのは当然のことです。しかし、Win16プロテクトモードアプリのサポートが(少なくとも一見)合理的に実装可能であり、Win32の新しいバージョンに含まれているように見えるのに、なぜそれらのサポートが除外されたのですか?実装コストを正当化するのに十分なほど高くないという需要の問題でしたか(そしてwin32バージョンはすでに実装されていました)、それとも技術的な理由がありますか?
実際のWin16プロテクトモードアプリはないと思います。 Windows/286以降がプロテクトモード(Microsoftでは「標準モード」または「拡張モード」と呼ばれます)で実行されていることは理解していますが、アプリは技術的にはリアルモードのアプリでした。
Windowsチームがプロテクトモードのオペレーティングシステムでリアルモードのコードを実行する方法を見つけたのは、マイクロソフトにとって驚きだったと読んだことを覚えています。しかし、ロングモードでリアルモードコードを実行するための同様のソリューションはおそらく存在しません。
したがって、問題は、a)Win16アプリを実行するためにプロテクトモード(またはリアルモード)に切り替えない理由、およびb)エミュレーター(他の非x86 NTプラットフォームのように)を含めない理由に帰着します。
ロングモードと他のモードの切り替えは、CPUが再起動せずにサポートするものではないため、a)の答えは明らかだと思います。 OS/2 1.xは、プロテクトモードとリアルモードで同じ問題を抱えており、問題に対する非常に洗練されていない解決策しか提供していませんでした。
B)の答えはもっと難しいですが、次の3つの点に基づいたMicrosoftの決定に帰着すると思います(私はリストが大好きです)。
まだ16ビットアプリを実行している人はほとんどいません。
そうする人はそれらを実行するために32ビットWindowsを実行することができます。
サードパーティ製品は残りの市場をカバーすることができます。
実際、Microsoft独自のVirtual PCを含め、64ビットWindowsで32ビットWindows(したがって16ビットアプリ)を実行するためのソリューションがいくつかあります。
全体として、これは、WindowsXPでの16ビットOS/2互換性の削除のような、レガシープラットフォームとの互換性(Microsoftが考えるもの)のサポートを停止するという単なる決定でした。 (これらは16ビットプロテクトモードアプリでした。)
@AndrewJBrehmの答えは良いですが、私が付け加えたい2つのポイントは、16ビットサポートを削除すると、64ビット製品のメンテナンスがより簡単で安全になるということです。 16ビットサブシステムのために何年にもわたって構築されたテストケースの数を想像してみてください。変更を加えるときはいつでも、何も壊れていないことを確認する必要があります。特に(比較的)めったに使用されない16ビットサブシステムのようなサブシステムは、攻撃者にとって適切なターゲットです。