clr - 再告诉我为什么我们需要 .NET 和 Windows？为什么 Windows 不能变成 CLR？

Question

DOS 变成 Windows 的方式是一样的吗？

我们似乎最终支持和开发了 Microsoft 的三个平台，我不确定边界应该在哪里。

为什么不能将 CLR 的好处(例如类型安全、内存保护等)内置到 Windows 本身中？

还是进入浏览器？为什么是一个完全不同的虚拟机？ (我们现在处理的虚拟机间接级别如何？我们刚刚添加了 Silverlight - 在 Flash 之前 - 在浏览器中运行，可能是虚拟机安装......)

我可以看到用于服务器的原始 Windows，但是为什么不能有用于工作站的 CLR 直接与硬件对话(或者至少不是整个 Windows 传统球和链)？

(ooppp - 我在这里有两个问题。让我们来解决这个问题 - 为什么 .net 不能内置到 Windows 中？我了解向后兼容性 - 但是 .NET 中的安全性至少可以选择在 Windows 本身中，不能不是吗？它只是许多 API 集合中的另一个？)

Factoid - 我记得在 IBM PC 上针对 MS-DOS 销售的竞争架构之一是 UCSD-pascal 运行时 - 一个 VM。

Answer 1

让我们不要忘记 DOS 并没有演变成 Windows，至少不是我们今天所了解和喜爱的 Windows。 DOS 是操作系统，Windows 3.1 是位于所述操作系统之上的 GUI shell 。

当 Windows 95 出现时，确实没有更多标有“Microsoft DOS”的盒装产品，但 Windows 95 在架构上是 DOS 7.0，上面有一个 GUI shell 。

这一直延续到 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 年。说实话，它可能会更长，因为虽然托管代码是一件很棒的事情，但它并不总是最合适/最好的答案。

另外……作为一名程序员，你应该比任何人都清楚:做某事从来没有表面看起来那么容易!