Скажите еще раз, зачем нам нужны .NET и Windows? Почему Windows не может превратиться в CLR?

Question

Точно так же, как DOS трансформировался в Windows?

Мы, похоже, в итоге поддержали и разработали для трех платформ от Microsoft, и я не уверен, где границы должны лежать.

Почему преимущества CLR (такие как безопасность типов, защита памяти и т. Д.) Не могут быть встроены в саму Windows?

Или в браузер? Почему совсем другая виртуальная машина? (Как с уровнями косвенного обращения к виртуальной машине мы имеем дело сейчас? Мы только что добавили Silverlight - и до этого Flash - работающий в браузере, работающем внутри, может быть, при установке виртуальной машины ...)

Я вижу сырую Windows для серверов, но почему не может быть CLR для рабочих станций, напрямую взаимодействующих с аппаратным обеспечением (или, по крайней мере, не со всей прежней системой Windows)?

(ooppp - у меня здесь два вопроса. Давайте сделаем это - почему .net не может быть встроен в Windows? Я понимаю обратную совместимость - но безопасность того, что находится в .NET, может быть как минимум в Windows само по себе, не так ли? Это был бы просто еще один из множества наборов API?)

Фактоид - я вспоминаю, что одной из конкурирующих архитектур, продаваемых против MS-DOS на IBM PC, была UCSD-pascal runtime - VM.

Answer 1

И давайте не будем забывать, что DOS не превратился в Windows, по крайней мере, в Windows, которую мы знаем и любим сегодня. DOS - операционная система, Windows 3.1 - оболочка графического интерфейса, расположенная поверх указанной операционной системы.

Когда вышла Windows 95, это правда, что больше не было коробочного продукта с надписью «Microsoft DOS», но архитектурно Windows 95 была DOS 7.0 с оболочкой графического интерфейса поверх.

Это продолжалось через Win98 и WinME (он же Win9X).

Windows, которую мы знаем сегодня (XP, Vista, 2003, 2008), имеет ядро ​​из проекта Windows NT, совершенно отдельного зверя. (Несмотря на то, что NT был разработан для совместимости с 3.1, а затем с 9-кратным двоичным кодом, и использовал почти идентичный, но расширенный API.)

DOS трансформировалась не более в знакомую нам Windows, чем оригинальное ядро ​​Linux, трансформировавшееся в KDE.

Два API-интерфейса должны будут продолжать сосуществовать, пока существуют продукты, изначально созданные для Windows, которые все еще находятся в цикле поддержки. Учитывая, что API Windows по-прежнему существует в Windows Server 2008 и Windows 7, это означает, по крайней мере, 2017 год. По правде говоря, он, вероятно, будет длиннее, потому что хотя управляемый код - это замечательная вещь, он не всегда является наиболее подходящим / лучшим ответом.

Плюс ... Как программист, вы должны знать лучше, чем кто-либо: никогда не бывает так легко сделать что-либо, как это может показаться снаружи!

Answer 2

Windows - это многомиллионные строки кода, большая часть которых написана на C. Это представляет собой огромные десятилетние инвестиции. Он постоянно поддерживается (исправляется) для современных пользователей. Было бы совершенно невозможно остановить мир, пока они переписывают каждую строку в C # на десять лет, а затем отлаживать и оптимизировать еще на десять, не полностью разрушая их бизнес.

Часть существующего кода теоретически может быть скомпилирована для запуска на CLR, но это не принесет никакой пользы. Компиляция большого подмножества C в CLR возможна (с использованием компилятора C ++ / CLI), но, к примеру, она не включает автоматический сбор мусора. Вы должны изменить дизайн с нуля, чтобы получить это.

Answer 3

Ну, для одного CLR не является операционной системой. Это довольно серьезная причина, почему нет ... Я имею в виду, что даже исследовательская ОС Singularity - это не просто CLR. Я думаю, вам следует почитать некоторые книги о ядре Windows и общих материалах об операционной системе.

Answer 4

Microsoft все еще в нескольких выпусках Windows.
Но они начнут с чего-то вроде Сингулярность Я думаю.

Answer 5

Самая большая проблема, которую я вижу, заключается в том, что CLR работает на виртуальной машине, а виртуальная машина полезна в качестве уровня абстракции. Некоторые приложения .NET могут быть запущены в Linux (см. Проект Mono, я думаю, что они теперь совместимы с .NET 2), так что все это исчезнет. В C / C ++ или языках, которые напрямую взаимодействуют с аппаратным обеспечением, вы должны перекомпилировать свой код в различные двоичные файлы для каждой ОС и аппаратной архитектуры. Смысл наличия виртуальной машины в том, чтобы абстрагировать ее, чтобы вы могли написать код, собрать его и использовать точно такой же двоичный файл в любом месте. Если вы посмотрите на это с точки зрения Java, то они сделали свою работу гораздо лучше, используя свою виртуальную машину как модель «один раз запусти куда угодно». Те же java-классы будут работать в Windows, Mac и Linux без перекомпоновки (программист в любом случае технически выполняет эту работу).

Я думаю, что точка # 1 заключается в том, что .NET / CLR НЕ специфична для Windows, и IMO Microsoft только поможет комплекту языков .NET, только если приложит немного больше усилий к совместимости между ОС.

Answer 6

потому что это нарушит обратную совместимость? и основная архитектура чипов не совпадает с архитектурой VM? Они сделали аппаратное обеспечение для виртуальной машины Java некоторое время назад, но никто не заботился.

Answer 7

Поскольку у Microsoft огромное наследие, их нельзя просто отбросить. Компании вложили много денег в программное обеспечение для Windows и Win32, которое они не могут выбросить.

Answer 8

CLR или некоторая виртуальная машина может использоваться (используются виртуальные машины) для запуска операционной системы поверх нее. Но тогда возникает вопрос: что нужно использовать для создания виртуальной машины? Вероятно, C / C ++ или другой подобный язык и (в большинстве случаев), возможно, сборка в некоторых случаях для ускорения процесса.

Это означало бы, что у виртуальной машины все еще будут проблемы, с которыми Windows (или любая ОС) сталкивается сейчас. Как отмечали другие, некоторая часть ОС и связанных приложений может быть перенесена (или, как вы сказали, изменились) на виртуальную машину, но получение всей ОС поверх виртуальной машины не имеет большого значения. Причина в том, что виртуальная машина станет настоящей ОС, реализующей сборку мусора и другие защитные меры для ОС Morphed.

Это мои два цента. :)

Answer 9

Я действительно видел тенденции, что CLR будет внедряться глубже в программный стек. Я помню, что видел новейший программный стек Windows, некоторые библиотеки, связанные с CLR, были переведены на более низкие уровни.

Но CLR не превратится в окна, мы знаем, что обратная совместимость очень важна для экологии программного обеспечения.

Answer 10

Какой язык будет использовать сам CLR? Какие API это будет называть? Скажем, нужно открыть файл, выделить память или создать процесс. Как вы думаете, CLR собирается это сделать? CLR построен поверх собственного кода. Управляемая ОС создаст дополнительную нагрузку.

CLR предназначен для разработки приложений, он предназначен для того, чтобы упростить создание приложений и облегчить создание программного обеспечения с меньшим количеством ошибок. Он использует сборщик мусора, и они могут снизить производительность. Они тоже могут быть хорошими, но у вас обычно возникают проблемы с производительностью во время разработки, вызванные сборкой мусора.

Они должны сделать его обратно совместимым, поэтому они должны иметь какой-то нативный API.

Если вы говорите, давайте создадим полностью управляемую ОС на 100% и забудем о обратной совместимости или сделаем позже гигантскую совместимость, то все, что вы на самом деле говорите, это давайте навязывать сборщик мусора на все, верно? Помимо сборщика мусора и переносимости гарантирует, что вы получите, будучи CLI-совместимым, что вы получаете? Алгоритмы и все остальное компилируются в собственный код к тому времени, когда они выполняются, поэтому единственное действительно существенное отличие - это управление памятью.