@Wolfdp

Сообщения перенесены из темы Как компилить программу .exe в другое разрешение?

---

не страдать ерундой.
.net является платформой, которая требует хостовой системы. Она по определению не подходит для создания собственной ОС, максимум -- виртуализации.

0

@Storm23

Ну .NET может и не подходит, но на C# оси пишут: CosmosOS.

Crypt0r, А вы не теряйте зря времени. Ось вы не напишите. Поиграйтесь с песочницей (ссылка выше), хоть какой-то толк может будет. Для начала сделайте хотябы свою файловую систему. Ну а про компиляцию exe в vut - забудьте.

0

@Wolfdp

ммм... читнул описание, вроде это просто управляемая ОСь, которая постороена на IL2CPU и Т.е. по сути некий конструктор на базе, мол взял шаблон, допилил что нужно, и получил кастумную ОСь.

0

Psilon

Wolfdp, Singularity был на шарпе полностью написан (не считая 5k sloc ядра на плюсах).

0

@Wolfdp

Psilon, в вики чуть иная инфа. Писали на Sing# (специально доработанном для данного проекта диалекте C#) с использованием небезопасного режима(!), а низкоуровневый код на ассемблере и С. Т.е. не в дефолтной сутдии с использование дотнета. Вообще, если так прикинуть, то можно хоть в блокноте писать, главное получить на выходе терубемый нябор байтов...

0

Psilon

Wolfdp, ну да, там не чистый шарп, ансейф все еще остается managed-языком, а про низкоуровневый код я вроде написал, там на нем фактически был только загрузчик. Надо ведь как-то загрузить JIT и все остальное, иначе как шарп заработает?

Почему ОС должна быть написана в дефолтной студии и таргетить дефолтовый дотнет мне непонятно. Главное - пример. Причем, он живет в винде, собственно linux2windows subsystem это дальний потомок этой самой Singularity. Так что все работает на практике. Что вполне доказывает жизнеспособность подхода.

0

@Wolfdp

я протупил, скорее нужно указать что класические студийньіе проектьі под .net не заточеньі для написания ОС. Студия же по сути навороченьій блокнот для лучшей нафигации кода и подключения нужньіх вещей в проект для работьі.

Я бьі сказал, что писать на .net ОС, єто как делать сайт не на asp.net, а тупо в консоли создавать Socket для прослушки, парсить входящие данньіе и отдавать в поток ответ. Т.е. технически єто можно. Наверное.... И даже удобней, чем Паскале. Но как-то не то...

Возможно есть какой-то проект, что написан для VS и использует синтаксис C#, но если не ошибаюсь, машиный код работает с памятью напрямую, а значит привет адресация и прочие прелести небезопасного кода, что немного противоречит изначальной идеи шарпа.

0

@Diamante

0

Psilon

Wolfdp, ансейфа там совсем немного, потому что в наше время неизвестно случаев написания системных вещей без валидации. Собственно, сама математика основывается на аксиомах, которые не доказываются, а принимаются. Ансейф на нижнем уровне - это и есть аксиомы программирования, на которых уже строятся безопасные вещи. Но нижний уровень - ансейф и избежать этого нельзя, даже в Rust - самый безопасный и низкоуровневый язык из существующих - в служебных библиотеках полагается на unsafe. Это раз.
Два - у того же С++ нет никакого преимущества по сравнению с шарпом в плане написания ОС. Просто когда писали основные из существующих ОС - ничего другого не было. В тех же мобилках (возьмем например андроид), системный код написан на джаве, плюс небольшой загрузчик на С++, который загружает JVM. Никаких проблем с тем, что система работает в managed-среде нет.

0

@Wolfdp

нядоже чем-то разабвлять постояные темы аля "как няйти символ в строке?"

Я понимаю что без него никак, просто идеология JAVA и C# -- писать конечный продукт быстро и не запариваясь, как правило бизнес-приложений. Ради этого вводились различные фичи (тот же Linq для лучшей работы с перечислениями, или асинхроность с локерами ради паралелизации действий, ну или лямда для мапинга и простотьі/читаемости).

Я плохо выражаюсь. Я не говорю что сам шарп не подходит для написание ОСей. Вообще C# это синтаксис, кто его реализует -- немного другая тема. Если вспоминать теорию вычислительной техники, всю (!) логику можно постоить на одной единственной булевской функции обратное-AND. Т.е. вопрос не в возможностях инструмента, а насколько он подходит для решения задачи.

Т.е. у нас есть ОСь, которая способна только запустить JVM, а уже дальше пляшем от нее? =) Можно сказать, что мы написали клон винды, который на старте запускает виртуал бокс, а уже дальше пляшем от него. Утрирую конешно, но я просто не понимаю, как мы обойдемся одним шарпом и платформой .net, если она не особо расчитана на работу с железом. =\

К чему я? Т.е. стоит задача создать ОСь со своим расширение исполняемого файла. Нам нужнен инструмент, который будет эмулировать железо, будет иметь блок часто используемых решений, инструмент отладки, и возможность все это собрать в готовый продукт.

p.s. я понимаю, что сейчас похож на истеричку, вопящую "на шарпе написать винду нельзя" XD , а если вспоминать изначальную задачу темы и ответ автора, то изначала стояла задача конфертировать exe в vut, потом всплыло что ребята пишут ОСь, но не говорили прямо что на шарпе или плюсах. Если говорить просто -- какому-то даєву сейчас прилетит RO... =(

p.p.s. пить вредно... серьезно, зачем я вообще думаю про все это, я что знаю ассемблер или собираюсь учится писать операционки?! >.<

0

Psilon

Ложная дихотомия. Почему писать производительный код должно быть болью? Мы уже имеем факт, что писать на С и быстрее, и легче, чем на ассемблере. Чем дальше в лес - тем лучше будет справляться компьютер с кодогенерацией. На примере SQL мы это и видим. Мало кто способен написать такой эффективный код, который генерирует оптимизатор SQL. А все потому, что там всё декларативно. ФП это тоже декларативно. "вот есть редьюсер, который так-то преобразует входные данные" против "а мы вот тут в цикле пройдемся и помножим все на два". В первом случае у оптимизатора развязаны руки, во втором случае - сорян.
судя по примеру сингулярити - если слегка допилить напильником (добавить пайпы, тот же async/await был более серьезным изменением, чем это), то весьма ок. звучит как реактос
Не вижу в ней ничего такого, что не дает работать с железом. Отсутствие реального времени из-за GC - да, пожалуй. Но все остальное - увольте. Исполняемый файл это фактически способ объяснить винде, как его запускать, используя дефолтный лаунчер. Используя кастомный можно вообще что угодно делать. Заголовки и т.п. - это просто стандарт а-ля JSON или XML. Соблюдаешь - имеешь фишки поддержки со стороны других инструментов. Нет - никто не заставляет, но для работы придется писать свои загрузчики/парсеры/...
Звучит как однострочник на powershell:
Действительно. Думать вообще вредно Заводятся эти, как их... Мысли, во!

0

@Wolfdp

Я к тому и веду, что из шарпа эта писанина будет болезнена. Написать прослойку легче на асемблере. А вот дальнейший софт для конечного пользователя можно делать из более высокоуровнего кода.

Если я правильно помню курс универа, то асемблер позволяет использовать командьі CPU. В шарпе такого не помню. =\

я так понял ТС подразумевал что оно будет запускаться на самописной ОСь. Учитьівая что писанина на шарпе требует платформьі, ее пришлось бьі внедрядь в операционку (с заменой вьізьіваемого расширения, хз насколько єто сложно сделать). Либо декомпилить, преобразововать код в нужньій и билдить под новую ОСь.

Я так понимаю, реально накатать библиотеку, которая под вьібраньіе параметрьі будет генерит определеное ядро. Возможно будет некая прослойка для "опускания" кода до машиного. Пока для меня єто звучит как "чтобьі начать писать на .net ОСь, нам придется обучить сам .net всей работе с железом напрямую, все єто обернуть и красибо оформить". Хотя неееет... єто звучит, как будтно мьі на фреймверке напишем инструмент для создания осей. Вот єто более вероятньій сценарий, как по мне.

0

Psilon

Почему это?
Ассемблер это и есть команды CPU. Шарп, очевидно, позволяет это делать, т.к. это ЯП. Конечно, делать инлайн-инстринки на ассемблере на шарпе трудно (хоть и не невозможно, см. например мой пример CPUID на форуме), но это и не нужно.
А на эту новую ось портирован .Net? Хотя бы Core? Потому что иначе вопрос чисто философский.
.Net и так умеет работать напрямую, когда ему это нужно. Просто где-то было удобнее переиспользовать существующие апи.

0