DOS演变成Windows的方式相同吗？
我们似乎最终支持和开发了微软的三个平台，我不确定界限应该在哪里。
为什么不能将 CLR 的好处（例如类型安全、内存保护等）内置到 Windows 本身中？
还是进入浏览器？为什么要使用完全不同的虚拟机？（我们现在如何处理虚拟机间接级别？我们刚刚添加了 Silverlight - 并且在此之前的 Flash - 在浏览器中运行，在其中运行可能是 VM 安装......）
我可以看到用于服务器的原始 Windows，但为什么不能有一个用于工作站的 CLR 直接与硬件对话（或者至少不是整个 Windows 遗留系统）？
（ooppp - 我这里有两个问题。让我们做这个 - 为什么不能将 .net 内置到 Windows 中？我了解向后兼容性 - 但是 .NET 中的安全性至少可以在 Windows 本身中选择，不能不是吗？它只是许多 API 集合中的另一个？）
Factoid - 我记得 IBM PC 上针对 MS-DOS 销售的竞争对手架构之一是 UCSD-pascal 运行时 - 一个 VM。
我们不要忘记 DOS 并没有演变成 Windows，至少不是我们今天所知道和喜爱的 Windows。DOS 是操作系统，Windows 3.1 是位于所述操作系统之上的 GUI 外壳。
当 Windows 95 出现时，确实不再有标有“Microsoft DOS”的盒装产品，但 Windows 95 在架构上是带有 GUI 外壳的 DOS 7.0。
这一直持续到 Win98 和 WinME（又名 Win9X）。
我们今天所知道的 Windows（XP、Vista、2003、2008）的核心来自 Windows NT 项目，这是一个完全独立的野兽。（尽管 NT 被设计为与 3.1 和更高版本的 9x 二进制文件兼容，并且使用了几乎相同但扩展的 API。）
DOS 演变成我们熟悉的 Windows 就像最初的 Linux 核心演变成 KDE 一样。
只要有针对 Windows 原生构建且仍处于支持周期的产品，这两个 API 就需要继续共存。考虑到 Windows API 仍然存在于 Windows Server 2008 和 Windows 7 中，这意味着至少 2017 年。说实话，它可能会更长，因为虽然托管代码是一件很棒的事情，但它并不总是最合适/最好的答案。
另外……作为一名程序员，你应该比任何人都清楚：做某事从来没有从外面看起来那么容易！
Windows 包含数百万行代码，其中大部分是 C 语言。这代表了长达数十年的巨大投资。它一直在为今天的用户维护（修复）。在他们用 C# 重写每一行十年，然后再调试和优化另外十年，而不完全破坏他们的业务的情况下，完全不可能阻止这个世界。
一些现有的代码理论上可以编译为在 CLR 上运行，但这样做不会获得任何好处。将 C 的大部分子集编译到 CLR 是可能的（使用 C++/CLI 编译器），但它不会自动启用垃圾收集，例如。你必须从头开始重新设计才能做到这一点。
好吧，CLR 不是一个操作系统。这是为什么不这样做的一个很大的原因......我的意思是即使是研究操作系统，Singularity，也不仅仅是 CLR。我认为您应该阅读一些有关 Windows 内核和一般操作系统内容的书籍。
微软距离那个版本还有几个 Windows 版本。但他们会从我认为的奇
点之
类的东西开始。
因为它会破坏向后兼容性？和主流芯片架构不符合VM架构？他们不久前为 Java VM制造了硬件，但没人关心。
我看到的最大问题是 CLR 在 VM 上运行，而 VM 作为抽象层很有用。一些 .NET 应用程序可以在 Linux 上运行（参见 Mono 项目，我认为它们现在可以与 .NET 2 兼容），所以这一切都将不复存在。在 C/C++ 或直接与硬件对话的语言中，您必须针对每个操作系统和硬件架构将代码重新编译为不同的二进制文件。拥有 VM 的目的是将其抽象化，以便您可以编写代码、构建代码并在任何地方使用完全相同的二进制文件。如果您从 Java 的角度来看，他们在将 VM 用作“一次编写，随处运行”模型方面做得更好。相同的 java 类将在 Windows、Mac 和 Linux 上运行而无需重新构建（无论如何，由程序员，从技术上讲，VM 正在做这项工作）。
我认为这里的第一点是 .NET/CLR 不是特定于 Windows 的，而且 IMO 微软只有在跨操作系统兼容性方面付出更多努力时才会帮助 .NET 语言套件。
因为微软拥有巨大的遗产，他们不能简单地放弃。公司已经为他们无法忽视的 Windows 和 Win32 软件投入了大量资金。
可能使用 CLR 或某些 VM（正在使用 VM）在其上运行操作系统。但接下来的问题是，应该使用什么来构建 VM？在某些情况下，可能是 C/C++ 或其他类似的语言和（大多数）可能是汇编以加快速度。
这意味着虚拟机仍然会遇到 Windows（或任何操作系统）现在面临的问题。正如其他人所指出的那样，操作系统和相关应用程序的某些部分可能会被移植（或如您所说的变形）以通过 VM，但是将整个操作系统置于 VM 之上并没有多大用处。原因是，VM 将成为真正的操作系统，对 Morphed 操作系统实施垃圾收集和其他保护措施。
那是我的两分钱。:)
CLR 本身会使用什么语言？它会调用哪些 API？假设它需要打开一个文件或分配内存或创建一个进程，你认为 CLR 会这样做吗？CLR 建立在本机代码之上。托管操作系统会产生开销。
CLR 是用于应用程序开发的，它可以让开发应用程序变得容易，并且可以轻松地制作更少错误的软件。它使用垃圾收集器，它们会破坏性能。它们也可以很好，但是你通常会在开发过程中遇到一些性能问题，这是由垃圾收集引起的。
他们必须使其向后兼容，因此必须使其具有某种本机 API。
如果你说让我们做一个纯 100% 托管的操作系统，然后忘记向后兼容性或者以后有一些巨大的兼容性，那么你真正想说的是让我们强制垃圾收集器到所有东西上，对吗？除了垃圾收集器和通过兼容 CLI 获得的可移植性保证之外，您还获得了什么？算法和所有内容在执行时仍被编译为本机代码，因此唯一真正重要的区别是内存管理。
实际上，我确实看到了 CLR 将深入软件堆栈的趋势。我记得看到过最新的 Windows 软件堆栈，一些 CLR 相关库被植入到较低级别。
但是CLR不会演变成windows，我们知道向后兼容对于软件生态非常重要。