2008-12-06 51 views
6

DOS变成Windows的相同方式?再次告诉我为什么我们需要.NET和Windows?为什么Windows不能变形到CLR中?

我们似乎已经结束了来自微软的三个平台的支持和开发,我不确定边界应该在哪里。

为什么CLR的好处(例如类型安全,内存保护等)不能嵌入Windows本身?

还是进入浏览器?为什么使用完全其他的虚拟机? (我们现在正在处理的虚拟机间接级别有多高?我们刚刚添加了Silverlight--在此之前,运行在浏览器内运行的浏览器可能是VM安装...)

我可以看到原始Windows for servers,但是为什么工作站直接与硬件直接对话(或者至少不是整个Windows传统的球和链)并不存在CLR?我在这里有两个问题,为什么不能将.NET内置到Windows中?我了解向后兼容性 - 但.NET中的内容的安全性至少可以选择Windows本身,不是吗?它只是众多API集合中的又一个?)

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

+0

看起来Win8(通过WinRT)正在开始这个过程。 – 2011-10-28 16:54:39

+0

或者至少预安装所有版本的CLR。 (是的,我的.net 2.0应用程序需要在Win8上安装.net 2.0 CLR,即使Win 8具有.net 4.0,大多数人说*是向后兼容的(如果您没有引用特定的2.0内容, 4.0) – 2012-11-14 19:50:56

回答

12

我们不要忘记,DOS并没有转变成Windows,至少不是我们今天所知道和喜欢的Windows。 DOS是操作系统,Windows 3.1是一个GUI shell,位于所述操作系统之上。

当Windows 95出来时,确实没有更多标有“Microsoft DOS”的盒装产品,但体系结构上的Windows 95是DOS 7.0的GUI外壳搁置在顶部。

这继续通过Win98和WinME(又名Win9X)。

我们今天所知道的Windows(XP,Vista,2003,2008)的核心来自Windows NT项目,它是一个完全独立的野兽。 (尽管NT被设计为与3.1以及后来的9x二进制文件兼容,并且使用了几乎相同但扩展的API。)

DOS没有更多的变成我们熟悉的Windows,而不是原来的Linux核心转变成的Windows KDE。

只要存在针对仍在支持周期中的Windows本机构建的产品,两种API就需要继续共存。考虑到Windows API仍然存在于Windows Server 2008和Windows 7中,这意味着至少2017年。事实上,它可能会更长,因为尽管托管代码是一件好事,但它并不总是最合适/最好的答案。

另外......作为一名程序员,你应该比任何人都了解得更清楚:从外部看来,做一件事情一点也不容易!

+1

嗯,我想这取决于“变形”的技术定义, ? :) – BobbyShaftoe 2008-12-06 05:13:35

3

因为它会打破向后兼容性?主流芯片架构不符合VM架构?他们made hardware前一个Java VM,但没有人关心。

+0

“变身”是指你看起来既像一会。显然,它具有支持现有的应用程序。 – dkretz 2008-12-06 05:21:50

2

由于微软已经获得了巨大的收益,他们不能只是简单地放弃。公司已经为他们无法忽视的Windows和Win32软件投入了大量资金。

8

那么,一个CLR不是一个操作系统。这是一个很重要的原因,为什么不......我的意思是即使是研究操作系统,奇点,不只是CLR。我想你应该阅读一些关于Windows内核和一般操作系统的书籍。

+0

当然它不是操作系统,但它是很充分的发展不失通过和伤害自己的OS之上的100%抽象,以及其他所有人你需要哪些资源通过CLR无法提供? – dkretz 2008-12-06 05:18:59

+0

我可以看到一些非常强大的操作系统和CLR集成的参数,例如,如果大对象堆对象被舍入到4K块,操作系统可以通过操作页面地图来重新定位它们,而不必实际复制大块内存 – supercat 2011-06-29 13:17:53

9

Windows有数百万行代码,大部分代码都是C代码。这代表了长达数十年的投资。对于今天的用户,它一直在维持(固定)。当他们用C#重写每一行十年,然后再调试和优化另外十个,而不会完全破坏他们的业务时,停止这个世界是完全不可能的。

一些现有的代码理论上可以编译为在CLR上运行,但它不会从中获益。例如,可以将C的大部分C编译到CLR(使用C++/CLI编译器),但不会自动启用垃圾回收。你必须从头开始重新设计才能获得。

1

可能会使用CLR或某些VM(正在使用VM)在其上运行操​​作系统。但问题是,应该用什么来构建虚拟机?可能C/C++或其他类似的语言和(大多数)大概在某些情况下大会,以加快事情。

这意味着虚拟机将仍然存在Windows(或任何操作系统)现在面临的问题。正如其他人指出的那样,操作系统和相关应用程序的某些部分可能会移植到虚拟机上(或者如您所说变形),但是将整个操作系统置于虚拟机之上并不会有很大的用处。原因是,VM将成为真正的操作系统,然后为Morphed OS实施垃圾收集和其他保护措施。

那些是我的两分钱。 :)

3

我看到的最大问题是CLR在虚拟机上运行,​​而虚拟机作为抽象层很有用。一些.NET应用程序可以在Linux上运行(参见Mono项目,我认为它们现在可以兼容.NET 2),所以这一切都将消失。在直接与硬件对话的C/C++或语言中,必须针对每种操作系统和硬件体系结构将代码重新编译为不同的二进制文件。让虚拟机具有抽象的意义在于,您可以编写代码,构建代码并在任何地方使用完全相同的二进制文件。如果你从Java的角度来看它,他们已经做得更好,把他们的虚拟机用作“一次写入一次运行”模型。相同的Java类将在Windows,Mac和Linux上运行,无需重新编译(无论如何,程序员在技术上都是VM正在完成这项工作)。

我认为这里的第一点是.NET/CLR不是Windows专用的,如果IMO为跨OS兼容性付出更多努力,它只会帮助.NET语言套件。

0

CLR本身会使用哪种语言?它会调用哪些API?说它需要打开一个文件或分配内存或创建一个进程,你认为CLR会这样做? CLR建立在本地代码之上。托管操作系统会产生开销。

CLR是用于应用程序开发的,它可以使制作应用程序变得容易,并且容易制作更少的软件。它使用垃圾回收器,并且可能会破坏性能。它们也可以很好,但是在开发过程中通常会由于垃圾收集而导致某些性能问题。

它们必须使它向后兼容,所以它们必须使它具有某种本地API。

如果你说让我们做一个纯粹的100%,管理OS和忘记向后兼容或更高版本有一些巨大的兼容性,所有你真正想说的是,让我们强制垃圾收集到的一切,对不对?除了垃圾回收器和通过CLI兼容的可移植性保证,您还得到了什么?算法和所有内容在执行时仍然被编译为本地代码,所以唯一真正重要的区别是内存管理。

0

我确实看到了CLR将更深入到软件栈的趋势。我记得看到了最新的Windows软件堆栈,一些CLR相关的库被植入了较低的层次。

但是CLR不会变成窗口,我们知道向后兼容的软件生态环境非常重要。