DOS变成Windows的方式相同吗?
我们似乎最终支持并开发了微软的三个平台,我不确定边界应该在哪里。
为什么不能将CLR的好处(例如类型安全,内存保护等)内置到Windows本身?
或者进入浏览器?为什么要完全是其他虚拟机? (我们现在要处理的虚拟机间接层是如何处理的?我们刚刚添加了Silverlight - 在Flash之前 - 在浏览器内运行可能是一个VM安装......)
我可以看到服务器的原始Windows,但为什么工作站不能直接与硬件(或者至少不是整个Windows传统的球和链)进行CLR?
(ooppp - 我在这里有两个问题。让我们这样做 - 为什么不能将.net内置到Windows中?我理解向后兼容性 - 但.NET中的内容的安全性至少可以在Windows中使用本身,不是吗?它只是众多API中的另一组?)
Factoid - 我记得IBM PC上针对MS-DOS销售的竞争对手架构之一是UCSD-pascal运行时 - 虚拟机。
答案 0 :(得分:12)
让我们不要忘记,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年。说实话,它可能会更长,因为虽然托管代码是一件很棒的事情,但它并不总是最合适/最好的答案。
另外......作为一名程序员,你应该比任何人都更清楚:从外面看来,做起来并不容易!
答案 1 :(得分:9)
Windows是数百万行代码,其中大部分是C语言。这代表了长达数十年的巨大投资。它不断被维护(固定)给今天的用户。如果他们在C#中重写每一行十年,那么就完全不可能阻止这个世界,然后调试和优化另外十行,而不会完全破坏他们的业务。
理论上可以将一些现有代码编译为在CLR上运行,但这样做不会带来任何好处。可以将一大部分C编译到CLR(使用C ++ / CLI编译器),但它不会自动启用垃圾收集。你必须从头开始重新设计以获得它。
答案 2 :(得分:8)
好吧,其中一个CLR不是操作系统。这是一个很重要的原因,为什么不...我的意思是即使是研究操作系统,Singularity,也不仅仅是CLR。我想你应该阅读一些关于Windows内核和一般操作系统的书籍。
答案 3 :(得分:6)
微软仍然有一些Windows版本远离它 但他们会从我认为的Singularity开始。
答案 4 :(得分:3)
因为它会破坏向后兼容性?和主流芯片架构不符合VM架构?他们前一段时间made hardware用于Java VM,但没有人关心。
答案 5 :(得分:3)
我看到的最大问题是CLR在VM上运行,而VM可用作抽象层。一些.NET应用程序可以在Linux上运行(参见Mono项目,我认为它们现在可以兼容.NET 2),所以这一切都将消失。在C / C ++或直接与硬件通信的语言中,您必须为每个操作系统和硬件体系结构将代码重新编译为不同的二进制文件。拥有VM的重点是抽象,以便您可以编写代码,构建代码,并在任何地方使用完全相同的二进制文件。如果从Java的角度来看,他们在将VM用作“一次编写一次运行”模型方面做得更好。相同的java类将在Windows,Mac和Linux上运行而无需重建(无论如何,程序员从技术上讲VM正在进行这项工作)。
我认为这里的第一点是.NET / CLR不是特定于Windows的,而IMO Microsoft只会帮助.NET语言套件,如果它为跨操作系统兼容性付出更多努力。
答案 6 :(得分:2)
因为微软拥有巨大的遗产,所以不能简单地放弃。公司为他们无法解雇的Windows和Win32软件投入了大量资金。
答案 7 :(得分:1)
可能会使用CLR或某些VM(正在使用VM)来运行操作系统。但问题是,应该用什么来构建VM?在某些情况下可能是C / C ++或其他一些类似的语言和(大多数)可能的汇编来加快速度。
这意味着VM仍然会遇到Windows(或任何操作系统)现在面临的问题。正如其他人所指出的那样,操作系统和相关应用程序的某些部分可能被移植(或者如你所说的那样)通过虚拟机,但是将整个操作系统放在虚拟机之上并不是很有用。原因是,VM将成为真正的操作系统,为Morphed OS实施垃圾收集和其他保护措施。
这是我的两分钱。 :)
答案 8 :(得分:0)
CLR本身使用什么语言?它会调用哪些API?假设需要打开文件或分配内存或创建进程,您认为CLR会这样做吗? CLR构建在本机代码之上。托管操作系统会产生开销。
CLR适用于应用程序开发,它可以轻松制作应用程序,并且可以轻松制作较少的错误软件。它使用垃圾收集器,它们可以破坏性能。它们也可能很棒,但是在开发过程中通常会遇到一些由垃圾收集引起的性能问题。
它们必须使其向后兼容,因此它们必须使其具有某种本机API。
如果你说让我们制作一个纯粹的100%托管操作系统而忘记向后兼容性或稍后有一些巨大的兼容性,那么你真正说的就是让垃圾收集器强行进入一切,对吧?除了垃圾收集器和可移植性保证您通过CLI兼容,你得到了什么?算法和所有内容在执行时仍然被编译为本机代码,因此唯一真正重要的区别是内存管理。
答案 9 :(得分:0)
我确实看到了CLR将更深入地植入软件堆栈的趋势。我记得看过最新的windows软件堆栈,一些CLR相关库被种植到较低级别。
但CLR不会变成窗口,我们知道向后兼容性对软件生态非常重要。