.NET (наболело) (10 стр)

Feaerenil
>ладно, хватит болтать: напишите нам, сирым, загрузчик на шарпах, переход в защещенный режим (опционально), и вывод сообщения привет мир на черном экране- я думаю, на этом вопрос и будет исчерпан
Блин, ну чего вам так не понятно. На асьме и сях пишется загрузчик, тонкая прослойка над железом и базовая функциональность виртуальной машины. А поверх этого - всё managed.

NightmareZ
это, вообще-то, и пытаются тут человеку объяснить

KenGoJin
ВОТ ТОЛЬКО НЕ НАДО УТВЕРЖДАТЬ, ЧТО НИКСЫ СДОХНУТ, А ВИНДА ОСТАНЕТСЯ
поздно уже...
что, большинство серваков в нете на винде работают?!
низашто не поверю...

NightmareZ
Достроил бы фразу:

"На асьме и сях пишется хрустящий загрузчик, тонкая прослойка над железом и нежная базовая функциональность виртуальной машины. А поверх этого - толстый густой слой managed..." - получилась бы реклама. (я не со зла, просто не смог удержаться =) )

Хозяин
>что, большинство серваков в нете на винде работают?!
M$ всё для этого делает. Хыхы... вчера листал PCWeek - там реклама WS2003: "Windows Server обгоняет Линукс!" Я чуть с лавки не упал... После такой "газеты для начальства" как-то нехорошо становится.

~X~
маркетологи...
никсы просто никто не раскручивает, да и не нуждаются они в рекламе...

Pyromaniac
да Вы батенька Петросян :)
будем считать, что Вы не знаете ответа на вопрос, что такое операционная система :)

--------------------------------------------------------------------------
потешная у мелкософта наверн ось получится на .Net))

для начала рассмотрим фразу "безопасный код":
- как минимум это означает, что этот исполняемый код безопасен для системы, остальных приложений и пользовательскийх данных  (то есть, если он внезапно грохнется, то остальных не заденет)
- во-вторых, да, в .Net есть гибкая настройка прав выполнения кода, что позволяет урезать количество свобод запускаемой программы, к сожалению (а может и к счастью) касается только .Net и на нативные приложения не распрастраняется...
- в-третьих, .Net просто таки блещет обилием вылетаемых исключений, при этом, не дай бог вам их не обработать - положет программу сразу, а точнее экземпляр "виртуальной машины"... но есть и такие, которые нельзя обработать (например, исключения, возникающие в mscore..) А если затронуть ещё и "во-вторых", то при запуске приложения с ограниченными правами - оно обязательно сложится из-за какого-либо внезапно вылетевшего исключения, потому как врядли будет расчитано на подобные вещи...
- в-четвертых, я уже и представить себе боюсь объекты ядра на .Net... особенно дрова, а если оттудова исключение вылетит?.. не положит ли это всю ось со всеми запущенными приложениями?...

в общем-то самая дорогостоящая, долгая и мучительная операция  - это смена архитектуры драйверов, которая обычно остается неизменной десятилетиями.. то есть, если и выпустят такую ось, то она ещё не скоро будет использована в различных областях, если только для рядовых пользователей, для домашних или офисных компов... В общем-то это и висты касается, либо там будут поддерживаться старые дрова, либо список поддерживаемых устройств будет заметно ограничен... для внутренних устройств - ещё куда ни шло (просто виста не пойдёт на старой аппаратуре, а к новой уже дрова напишут), а что делать со внешними?.. выкинуть?..
Не забывайте про назначение операционной системы, у каждой оно своё ;-)

возникающие ассоциации с managed ядром операционной системы:

- managed process manager (а может ли такое быть?..)
- managed memory manager (уже смешно? :) )
- (про контроллер прерываний, DMA и тому подобные вещи я уж молчу...)
- GC (здесь без коментариев)
- managed объекты ядра  (какие объекты ядра GC может собрать, а какие нет?.. и вообще может ли собрать GC объекты ядра? Если нет, то что тогда с ними делать, как удалять?..)

и вообще, каким должно быть "managed" ядро - микроядро, макроядро?.. какая должна быть тама многозадачность внутри ядра - вытесняющая или кооперативная?...

В общем, ответы на эти вопросы даст тока мелкософт после выпуска своей "полностью" managed операционной системы :) я уже жду с нетерпением, чтобы взглянуть на это чудо :)

Xaf
Ну по поводу петросяна - какой вопрос, такой и ответ ;)

А по поводу всего остального - почти согласен, только тут есть некоторые фанаты, которым лениво читать посты других или думать (зато не лениво батоны топтать)... Боюсь им просто невозможно ничего доказать. Так что больше тут отписываться не буду - нервы поберегу...

RPGman
Укажи принципиальную разницу.

NightmareZ
>Блин, ну чего вам так не понятно. На асьме и сях пишется загрузчик, тонкая
>прослойка над железом и базовая функциональность виртуальной машины. А поверх
>этого - всё managed.

Не нервничай. Они не могут ничего ответить, так как ничего не знают. Кроме того, немного труда и асма с сями ненужно.
На мой простой вопрос, какие книги надо почитать, чтобы убедиться в их правоте - только отмазки.
Из этого можно сделать вывод, что они сами ничего не читали.

Всем остальным
Я внимательно читаю посты, иногда по 2-3 раза, чтобы понять, что человек имел в виду.
Если Вы не читаете мои посты или не понимаете их спрашивайте что я имел ввиду.
Пока же я вижу ничем не аргументированное тыкание в меня пальцем с криком "Фанат и тормоз!"

А проблема, по которой мы завелись простая:
Вы говорите принципиально нельзя написать на Манагед ОС. Аргумент: Идите читайте книжки (не указывая автора и названия)
Я говорю, принципиально можно. Указываю методы решения проблемы. Могу указать даже список книг, которые я прочитал, чтобы у меня сложилось такое мнение.

Pyromaniac
То есть, у вас принципиально нет аргументов не высосанных из пальца?
Но как же книги? Назовите книги, которые я должен прочитать?

Xaf
Согласитесь, все эти проблемы не смертельны и не несут с собой принципиальной невозможности написания Managed OS.
Проблема состоит из стоимости реализации и времени потраченного на разработку. Однако Microsoft может это себе позволить.

SlavaGorbacheff
>Укажи принципиальную разницу.
Разница та, что ядро не собирается потом. Линух в данном случае уместно сравнивать с XP. Купил ДВД для своего компа, поставил и радуйся.
Ядро пересобирают только фанаты-хардкорщики. Все этапы пересборки нативные во всех ипостасях, и делаются далеко не на лету.
И ни в одном месте этого процесса нет еще одного уровня абстракции в виде промежуточного компилятора. Для чего оно, объясни?
Зачем две фазы компиляции? Зачем ядру jit-компиляция? Ты собираешься часто запускать один и тот же экземпляр ядра на абсолютно
разных компах?

>Я говорю, принципиально можно. Указываю методы решения проблемы.
Где ты указал метод решения проблемы написания на MSIL компилятора с MSIL, исполняемого с адреса ffff:0000 ?

SlavaGorbacheff
с удвольствием посмотрю на это "чудо" :)
жду с нетерпением :)

Xaf
http://research.microsoft.com/os/singularity/
http://www.rsdn.ru/article/singularity/singularity.xml
http://ru.wikipedia.org/wiki/Singularity

а вообще пока процы не будут выполнять нативно MSIL код, ничего из этого нормального не выйдет. вотъ

RPGman

>>Укажи принципиальную разницу.
>Разница та, что ядро не собирается потом. Линух в данном случае уместно сравнивать с XP.
>Купил ДВД для своего компа, поставил и радуйся.
Ну, хоть в чем то улучшение.

>Ядро пересобирают только фанаты-хардкорщики.
Но все-таки, хоть ктото, но пересобирает?

>Все этапы пересборки нативные во всех ипостасях, и делаются далеко не на лету.
Вот вы сами и отвечаете на свой вопрос. Конечно, все делается на этапе инсталляции.

>И ни в одном месте этого процесса нет еще одного уровня абстракции в виде
>промежуточного компилятора. Для чего оно, объясни?
А там его и не будет. Поясняю ниже.

>Зачем две фазы компиляции? Зачем ядру jit-компиляция?
Какие две фазы? Вы имее ввиду из исходников в jit, а потом из jit в native? Но MSIL-компилятор реально нужен только программисту.
Соответственно, можно jit-компиляцию провести заранее и где угодно. А в момент инсталяции производить окончательную сборку.

Цитата из МСДН: Native Image Generator (Ngen.exe)
Creates a native image from a managed assembly and installs it in the native image cache on the local computer.

>Ты собираешься часто запускать один и тот же экземпляр ядра на абсолютно разных компах?
Не об этом речь, хотя опять-таки принципиальных проблем нет. Только нахрен такое монструозное ядро?
Но хочу заметить, что кроме ядра, все остальное можно спокойно переносить с машины на машину и запускать на выполнение.
На всех машинах где есть .Net Framework.

>Где ты указал метод решения проблемы написания на MSIL компилятора с MSIL,
>исполняемого с адреса ffff:0000 ?

Извини, я тебе предоставлю немного информации. По адресу ffff:0000 находится команда перехода на точку входа в биос.
Соответственно, до загрузки ОС, по меркам процессора, как до Пекина.

И кроме того, NGEN.EXE - может в принципе лепить любой "native image from a managed assembly"

так и вижу кусочек исходного кода:

 

using OS.Core;
using OS.BIOS;
using OS.Driver;

#pragma CoreAssembly

namespace MyCore
{
    static class ManagedCore : Core
    {
        /// <summary>
        /// The main entry point for the core initialization.
        /// </summary>
        [CORETread]
        static void Main()
        {
            Drivers.Init();
            Core.Run(new OS.MessageManager());
        }
    }
}

_ShaMan_
О нормальном никто не говорит. Говорят о возможном.

SlavaGorbacheff
>Какие две фазы? Вы имее ввиду из исходников в jit, а потом из jit в native? Но MSIL-компилятор реально нужен только программисту.
>Соответственно, можно jit-компиляцию провести заранее и где угодно. А в момент инсталяции производить окончательную сборку.
Скажи, в чем сила .net? Разве не в jit? Ты же обрезаешь это самое преимущество на корню. Просто ради факта написания лишнего уровня абстракции
на произвольном языке.

Да не, товарисчи. Можно, конечно, так мощно расширить функциональность любого компилятора (хоть с лиспа), что он хоть какой код низвёдет до самодостаточного кода в нативном ассемблере. В принципе. Видимо, про это нам тут отдельные товарисчи и пытаются втереть.
Да только есть проблемка одна - менее очевидная (для могучих теоретиков манагед кода), но оттого не менее принципиальная.

Любой язык - хоть Ц, хоть лисп, хоть ассемблер - описывает функционирование некоей Абстрактной Машины. Для ассемблера она самая простая (в смысле промежуточных прослоек) - совпадает с процессором, и никаких промежуточных прослоек нету.

Для Ц чуть посложнее - в неё, как минимум, требуется умение работать со стеком, выгребать из него локальные переменные, делать арифметику, а также производить вызовы функций в соответствии с некоторой конвенцией (правила передача параметров, возврата результата, и пр.) Это прослойка достаточно тонкая, её операции инлайнятся в небольшие наборы ассемблерных команд весьма элементарно. Но всё-таки она уже ненулевая. Но достаточно тонкая. Но ненулевая. Но тонкая. Для небольшого модуля на Ц, не использующего никаких библиотек, объём служебного кода, требуемый для поддержки данной абстрактной машины, практически нулевой. (При одном, правда, условии: что процессор аппаратно поддерживает стек и произвольный доступ в одной и той же области памяти. Если сие не так (а есть, говорят, такие извращённые процессоры), то реализация абстрактной машины для Ц усложняется, и толщина прослойки мгновенно сделается очень даже ненулевой.)

Абстрактная машина для Ц++ ещё сложнее. Появляются высокоуровневые фичи - new/delete и throw/catch. Для их поддержки уже требуется ощутимый по функционалу (и объёму) вспомогательный код: он должен уметь динамически распределять память из хипа, а также брать её откуда-то для объектов-эксепшенов. (Умел бы это делать сам процессор... но пока что - увы.)
В принципе, можно выкинуть из абстрактной машины эту поддержку, и на Ц++ по-прежнему можно будет жить. Но уже без указанных фич.

А теперь рассмотрим чего-нть такое очень манагед и безопасное. Например, некий гипотетический язык G++, по правилам которого локальные переменные функции не удаляются до тех пор, пока на них есть хоть одна живая ссылка. Например:

ref<some_object> my_ref,my_ref2;
function some_func ()
{
 some_object my_var,my_var2; // 2 локальнае переменные
 my_var.do_something (); // зовём какой-нть её метод
 &my_ref=my_var; // делаем на 1-ю переменную ссылку
 &my_ref2=my_var; // и ещё одну
}
...
some_func (); // вызвали функцию
// my_var2 уничтожилась, а my_var - нет,
// т. к. её помнят ещё живые my_ref и my_ref2!
my_ref.do_something (); // опять зовём какой-нть её метод
my_ref2.do_something (); // или вот так - оба раза всё правильно
my_ref=null; // одна ссылка отвязалась, но осталась вторая -
// my_var всё ещё живёт!
my_ref2=null; // а вот теперь и my_var удалилась

Можно с такого языка оттранслировать в ассемблер? Да не вопрос, можно. Только один нюанс: абстрактная машинка G++ должна поддерживать соответствующие механизмы распределения памяти под локальные переменные. Обычных процессорных средств для управления стеком не хватит - слишком сложные для простого стека правила удаления. Нужно что-то ещё (тот же хип), процессором не предусмотренное. А значит, это что-то (фрамеворк) тоже придётся реализовать ручками и включать в комплект. И этот фрамеворк уже довольно-таки тяжёл.
(Специально для оптимистов замечу: реализация хипа в наши дни - не такая простая задачка, как хотелось бы. Мы ведь не забыли, что на дворе защищённый режим, и логические адреса конвертируются в физические по весьма навороченным алгоритмам, включающим поддержку свапов?)

Но почему бы нам, как в Ц++, не выкинуть из абстрактной машины G++ эту тяжеловесную поддержку хипа, и не наслаждаться жизнью в оставшемся подмножестве G++?
А вот фигвам!
Почему мы можем безболезненно жить на Ц++ без new/delete и throw/catch? Потому, что оставшаяся часть языка вполне достаточна, чтобы рисовать полноценные программы. (И, к слову, куда более низкого уровня - без эксепшенов и new/delete для Ц++ требуется абстрактная машина не сложнее, чем для Ц).
В случае же с G++, с хипом повязаны переменные - фундаментальнейшие и незаменимые кирпичики языка. Причём повязаны неизбежно - на уровне языка. Если мы выкинем хип, то придётся отказаться и от переменных. Но тогда писать программу будет попросту нечем.
В результате - дилемма: если нам нужен G++, нам с необходимостью нужен и довесок в рантайме, поддерживающий хип.

Разумеется, можно этот довесок скомпилировать в ассемблер и куда-нибудь его засунуть - в RTL ли, в длл ли, в ядро ли ОСа. Но вспомним, что мы не веники собрались вязать, а сочинять ОС. Отсюда проистекает несколько следствий:

1. У нас неизбежно будут некоторые участки кода, которые принципиально должны быть самодостаточными (опираться на сервис более низких слоём они не могут, ибо сами и являются самым низким слоем, либо скованы ограничениями, типа запрета прерываний и пр.). Длл или поддержка ядра в данном случае отпадают - только RTL. Или, выражаясь в терминах ресурсов, дополнительный код в данные модули.
В случае с Ц или ненавороченным Ц++ (а тем более с ассемблером) объём дополнительного кода мизерен до пренебрежимости. (И то, когда речь заходит об бутовом загрузчике, даже такой объём становится критичным.) В случае с каким-нибудь G++ - уже нет. Даже если предположить, что мы соорудили управление хипом и счастливы - а всё ли мы учли? А подстраховку от утечек памяти? (Это только на прикладном уровне можно себе позволить чего-нть недоосвободить (ОС приберёт), а тут - самый низкий уровень, надеяться не на кого!) А в каком кольце защиты и адресном пространстве работаем? (Вдруг наши выкрутасы вызовут исключение на подгрузку страницы, а мы, собственно, как раз его и обрабатываем?) Запросто может оказаться, что на столь низком уровне нужный нам фрамемворк потребует различных реализаций не только на разных процессорах, но и для разных частей ядра и разных драйверов, например.
А если у нас не только хип, но и GC? Хи-хи.

2. Вопрос номер следующий: а на каком языке разработчеги пишут этот фрамеворк? Явно не на Том Самом Языке (ибо его абстрактная машина уже предполагает наличие готового фрамеворка).
Но, может, объём кода этого фрамеворка - на уровне "ассемблерных вставок", то бишь, только в критических местах и узкоспециализированный? Не смешите мои тапки. Конструкция, умеющая распределять память, разруливать свап и собирать гарбаж, уже сама по себе тянет на полноценное ядро. Иметь такую "ассемблерную вставку" и утверждать, что "...а так наше ядро написано на Том Самом Языке" - это верх наглости.
Особенно, если Тот Самый Язык не предоставляет средств для вставок кода на уровне нативного ассемблера.

Есть, конечно, и другой способ уменьшить зависимость языка от сложной абстрактной машины - ввести в него минимально необходимый набор конструкций для программирования на более низком уровне. (Те же ассемблерные вставки, например.) Тогда код, использующий только эти конструкции, обретёт бОльшую "самостоятельность". Но это будет уже расширение не компилятора, а самогО языка, что равносильно подгонке исходных условий под решение задачи. И, кроме того, напрограммленное из "низкоуровневых конструкций" будет уже никак не манагед. :)