1 Января был анонсирован выход операционной системы Sharpos полностью написанной на C#. В отличие от сингулярити эта ОС действительно написанна полностью на C#, для достижения этого они создали свой компилятор в Native и библиотеку ASM в которой есть все x86 команды. Пример вызова ASM.Mov(.. , ..). Когда компилятор встречает такой вызов тогда он вставляет эту команду непосредственно в код как есть.

Проект безусловно интересен для всех .net разработчиков, и доступен ввиде исходников, бинарников и образов для популярных виртуальных ПК. На сайте есть скриншоты и видео. Сорцы компилятора тоже доступны.

-----
have a nice day

| Сообщение посчитали полезным:

[offtop]
--> KolibriOS <-- http://www.kolibrios.org/
KolibriOS (англ. KolibriOS — КолибриОС) — любительская операционная система для PC, полностью написанная на ассемблере fasm, распространяемая на условиях GPL. Создана на основе MenuetOS. Система расчитана на использование ассемблера для написания приложений, но есть и программы, написанные на языках Ада, Си, C++, Free Pascal, Forth. Система использует собственные стандарты и не основана на POSIX и UNIX. На данный момент преимущественное большинство разработчиков живут на территории стран СНГ.
[/offtop]

| Сообщение посчитали полезным:

Интересная штука... не сама ОС (кстати очень правильно что в шапке "полностью на шарпе", а не "полностью управляемая") а компилятор додиеза в нитивный код. Как они там доказывают надёжность или правильность кода

| Сообщение посчитали полезным:

Не знаю как вы, но если в проге на ЯВУ используются ассемблерные вставки, то я не считаю прогу полностью написанной на этом ЯВУ. А расширенный С# для меня уже не С#. Это все равно что сказать, что linux написан на паскале. Просто из этого паскаля выкинули все возможности паскаля и добавили все возможности си.

Так что sharpoc написана неполностью на не С#, что бы там не утверждали ее авторы.

| Сообщение посчитали полезным:

ASM.Mov(.. , ..)
Жесть! Ну и С#...

С++ создавался для написания ядра ОС и системных программ.
А С# создавался для написания приложений. В принципе, лично я ничего не имею против C# как языка, но вот maged код...

| Сообщение посчитали полезным:

Dian

Видимо кто то думает, что писать ядро на строго типизированном языке лучше.

-----
have a nice day

| Сообщение посчитали полезным:

Интерес чисто спортивный ИМХО.

[offtop]
я пока не видел ни единой программы, написанной на С#, которую можно было бы ставить в пример лучшему софту написанному на чистом С, или С++. А то что я вижу регулярно - это ужаснах. Поэтому делаю вывод - язык для полных лентяев, и нашел свое место только благодаря уменьшеным трудозатратам на написание программ. Почему-то ненавижу этот язык
[/offtop]

-----
Research is my purpose

| Сообщение посчитали полезным:

я так и не понял, эта sharp os доступна для скачивания или нетвсё, нашёл... если кому надо:
puzzle.dl.sourceforge.net/sourceforge/sharpos/SharpOS-0.0.1.iso

-----
Do Not Get Mad Get Money! ;)

| Сообщение посчитали полезным:

ИМХО очередное геройство. Единственный успешный вариант - C + Unix, а попытки доказать, что "и мы не хуже Кернигана" (типа Modula + Oberon, Kolibri, etc.) как-то не очень жизнеспособны...

| Сообщение посчитали полезным:

Talula

https://sharpos.svn.sourceforge.net/svnroot/sharpos/trunk https://sharpos.svn.sourceforge.net/svnroot/sharpos/trunk

Error_Log

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

Archer: вроде, не маленький уже, а кнопкой правка пользоваццо не научился. =\ Стыдись, ветеран.

-----
have a nice day

| Сообщение посчитали полезным:

Nimnul пишет:
Видимо кто то думает, что писать ядро на строго типизированном языке лучше.
Строгая типизация - это проверка типов во время компиляции (например в С или С++, в отличие от javascript ;) А ASM.Mov - должно быть полное отсутсвие не только типизации, но и всяких выходов за границы массивов.

| Сообщение посчитали полезным:

ИМХО очередной выпендрёж. Полезно м.б. только в учебных целях и интересно для узкого кругв энтузиастов. Полноценную ось создать вообще утопично без финансовой поддержки, без ясной цели-концепции (для чего?, будет ли совместимость с уже созданными программами будь то виндоуз или линукс ?), без "правильного, надёжного, быстрого" языка программирования, без огромной команды (миллионы строк кода за год-два невозможно написать группой из 5-10 человек). Помню первое знакомство с БеОС в 2000 году, был просто потрясён скоростью загрузки, реагированием программ, производительностью на довольно слабом компьютере (пентиум 3, 550 Мгц), но... отсутствие драйверов, скудное программное обеспечение полностью охладило первое восхищение, и хотя с тех пор много воды утекло, и программ добавилось, и пользуюсь иногда Зетой, и жду первого релиза Хайку, но какая-то ограниченность, невозможность что-то определённое сделать, как в виндоузе или в линуксе, постоянно ощущается(поддержки джавы до сих пор нет). То же и в Кьюниксе. БСД надёжен, но для специфических целей. ФриДос, Колибри?!... Создание русской операционной системы? Да было бы просто замечательно, если опять же с правильной (выигрышной концепцией) целью. Надо учитывать, что поезд ещё в начале 90-х ушёл (облом или полуоблом ай-би-эм с полуосью!). Нужна Ось с поддержкой на уровне ядра всего наработанного человечеством (виндоуз, линукс, макос и т.д.) за счёт виртуализации, с оптимированным кодом да с учётом современной техники - осуществимо, для возможно большего количества языков, всё это может принести решающий успех. Это может оказаться началом конца мелкомягких... Ох, и занесло же меня куда-то... Сорри, за оффтоп.

| Сообщение посчитали полезным:

Nimnul, а зачем писать OS с ноля? Ядро линукса отличная база - работает на PC, на всяких ARM, PowerPC, VIA и т.д, драйверов - навалом, весь исходник есть. Запустить на новой плате (с одним из этих процов) - несколько дней для опытного програмера. Нужна поддержка русского - есть, windows API - дополняй WINE, TCP/IP stack - порядок, красивый GUI - возьми и расширь любой window manager.

| Сообщение посчитали полезным:

...ради эксперимента, интереса и т.п. целей

| Сообщение посчитали полезным:

userdom пишет:
Надо учитывать, что поезд ещё в начале 90-х ушёл (облом или полуоблом ай-би-эм с полуосью!).
А могло быть по-другому?
Если ты не в курсе, то OS/2 для IBM писала как не смешно та же Microsoft.
Они что враги себе что-ли?
s0larian пишет:
Nimnul, а зачем писать OS с ноля? Ядро линукса отличная база - работает на PC, на всяких ARM, PowerPC, VIA и т.д, драйверов - навалом, весь исходник есть.
Подход ИМХО неправильный.
С таким подходом просто ничего нового бы не появлялось.
Зачем было писать Linux? Был ведь Minix под которым всё это писалось.

| Сообщение посчитали полезным:

S_T_A_S_

Если асм использовать, только там где надо, то все будет ок. C вобще не типизированный язык. Взять хотябы
char* v1 = ...; int* v2 = (int*)v1; C# за такое поругает. Не говорю уже о том, что в C# не бывает не правильных указателей, а ООП спасает от множества типичных ошибок в том числе и архитектурных. Но все это не о sharpos, то что у них C# имеет натив компилятор, отменяет все преимущества двух этапной компиляции, такой как в .net

-----
have a nice day

| Сообщение посчитали полезным:

Само собой, о серьёзности проекта пока говорить просто рано. Скорее всего, будет то же, что и с остальными любительскими осями...

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

[offtop]
Error_Log, я почему-то тоже С# не люблю - какие-то обрезки от с++ да сомнительные навороты типа foreach (кстати, последний идет из бейсика). Когда впервые попробовал что-то на C# писать надоело ждать запуска программы. От типобезопасности иногда больше вреда чем пользы - сидишь думаешь как сконвертировать вместо работы...
[/offtop]

| Сообщение посчитали полезным:

Dian
std::for_each Вам говорит о чем-нибудь?

| Сообщение посчитали полезным:

cppasm пишет:
С таким подходом просто ничего нового бы не появлялось.
Ядро было написано новое, но posix и все GNU библиотеки были просто перенесены. Именно по этому софт и компилится на разных unix-ах.

cppasm пишет:
Зачем было писать Linux? Был ведь Minix под которым всё это писалось.
Миних это не ось а игрушка, работающая в одном процессе реальное операционки. Написана была в целях обучения студентов. А Линус хотел нормальное ядро, с брайверами для PC.

| Сообщение посчитали полезным:

Nimnul пишет:
Если асм использовать, только там где надо, то все будет ок.
А кто решает, где надо? Вот любимый агрумент дотнетчиков - если компилятор не может проверить правильность кода, то код ненадежен ;)

Nimnul пишет:
C вобще не типизированный язык. Взять хотябы
char* v1 = ...; int* v2 = (int*)v1;
K&R C действительно быд нетипизированным языком (асм с кривым синтаксисом), а то, что ты написал, называется явное преобразование типов, а не обход их контроля. Пример с неявным кастом void* к указателю на другой тип был бы более уместен - это действительно дыра в контроле типов, которую запретили в С++.

censor пишет:
std::for_each Вам говорит о чем-нибудь
Это кстати просто компактная запись обычного for.

| Сообщение посчитали полезным:

Nimnul пишет:
Не говорю уже о том, что в C# не бывает не правильных указателей, а ООП спасает от множества типичных ошибок в том числе и архитектурных.
Отсюда вывод - C# язык для людей которые в силу кривизны своих рук не могут писать правильный код без таких костылей.

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

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным:

S_T_A_S_ пишет:
Это кстати просто компактная запись обычного for.
Ну да, конечно "for_each" это алгоритм который можно запустить на sequence containers. Вот кусок из моего кода реализующая observer pattern:

std::for_each(crawler.m_setHandlers.begin(), crawler.m_setHandlers.end(),
boost::bind(&NotificationHandler::Connected, _1));

проходит по всему множеству и вызывает Connected() метод.

Фичка, кста, уникальная для не-функциональных (lisp/scheme) языков.

| Сообщение посчитали полезным:

s0larian

Не уникальная. То же самое можно сделать в C#. причем даже больше приближенно к функциональным языкам. Типа:

array.ForEach( Connected );
array.ForEach( x => x + 10 );

Надо только класс соответствующий написать.

| Сообщение посчитали полезным:

Дык додиез просто функциональным языком становится ;) А std::for_each будет работать даже с голыми указателями. (и кстати на самом деле, он вообще никак не привязан к контейнерам).

ntldr
Ты наверное имеешь ввиду неявное приведение (расширение) типов?

| Сообщение посчитали полезным:

S_T_A_S_, for_each ожидает два итератора а не указатели.

| Сообщение посчитали полезным:

S_T_A_S_

Шарп сможет сделать все что делают алгоритмы из STL. Просто там будут не указатели, а IEnumerable.

Тут люди ругают C#....

Dian пишет:
От типобезопасности иногда больше вреда чем пользы - сидишь думаешь как сконвертировать вместо работы...

Это просто потому что опыта еще нет. После написания пары программ таких проблем не возникает, а вот когда компиллятор тебе показывает ошибки на этапе компилляции а не приходится их в дебагере часами искать, то это сильно упрощает дело.
В конце концов если так необходимо сделать непроверяемый каст указателя - написал unmanaged функцию - и все.


ntldr пишет:
Отсюда вывод - C# язык для людей которые в силу кривизны своих рук не могут писать правильный код без таких костылей.
Баги есть любой сколько нибудь серьезной программе. Если язык позволяет избежать каких-то багов, то почему бы этим не воспользоваться. Можно написать что-то в C++, потом линтить, дебагить и править баги. Или написать в три раза больше или в три раза сложнее в C#.
То что язык позволяет писать программы менее опытным программистам еще не значит что язык плохой.

| Сообщение посчитали полезным:

egorovshura пишет:
а вот когда компиллятор тебе показывает ошибки на этапе компилляции а не приходится их в дебагере часами искать, то это сильно упрощает дело.
Опытный программист – это не тот, кто знает один в идеале язык программирования и надееццо что за него компилятор найдет ошибки...
А тот, который знает не меньше пяти язык программирования в идеале(ASM в обязательном порядке)
И скриптовых языков не меньше десятка!
И выбирает для поставленной задачи наиболее оптимальный язык программирования
Учитывая все минусы и плюсы решения одной и той же задачи на разных языках программирования

Короче протЕв C# - это просто жалкие шекеля для издателей и всяких там писак книжек
Сабж это просто пиар и пошлое повышение самооценки программеров, типа теперь сними ASM %))
ASM.Mov(.. , ..). ппц. плакал поцталом!

-----
ЗЫ: истЕна где-то рядом, Welcome@Google.com

| Сообщение посчитали полезным:

s0larian пишет:
for_each ожидает два итератора а не указатели

Ок, давай подробно разберём, все равно уже оффтоп, а эта инфа мож пригодится кому-то еще.

Во-первых, итератор - это ни что иное, как обобщенный указатель (см. определение 24.1/1). Все STL алгоритмы, требующие итератор, будут работать с указателми как с random access iterators, поскольку есть специализации iterator_traits<T*> и iterator_traits<const T*>.

Во, вторых:

/// 25.1.1 For each [lib.alg.foreach]
template<class InputIterator, class Function>
Function
for_each(InputIterator first, InputIterator last, Function f)
{
while ( first != last ) f(*first++); // на драных компиляторах будет лучше for ( ; first != last; ++first ) f(*first);
return f;
};
От типа InputIterator требуется поддержка: инкремента, разыменовывания и сравнения. Для поинтера все эти операторы определены.

egorovshura пишет:
Шарп сможет сделать все что делают алгоритмы из STL. Просто там будут не указатели, а IEnumerable
Я не знаю додиез. Попробуем такой надуманный пример:

#include <algorithm>
#include <istream>
#include <iterator>
#include <iostream>
#include <cstdio>

int main()
{
using namespace std;
for_each
(
istream_iterator<char>(cin),
istream_iterator<char>(istream(0)),
putchar
);
}
egorovshura пишет:
Можно написать что-то в C++, потом линтить, дебагить и править баги.
На С++ многое можно, и это скорее один из плисов ;) А еще я видел как перловики тупо брали справочник по С++, садились и писали сложный софт, который при запуске просто начинал работать 24*7 без утечек и падений.

Demon666 пишет:
И выбирает для поставленной задачи наиболее оптимальный язык программирования
А потом дает ТЗ эксперту по этому языку =)

| Сообщение посчитали полезным:

S_T_A_S_, точняк, я не знал про специализацию для указателей.

| Сообщение посчитали полезным:

S_T_A_S_ пишет:
Я не знаю додиез. Попробуем такой надуманный пример:

Пример конечно красивый, но специфичный для C++ и STL. Такое делать никто не будет в реальной жизни. Что-то подобное в шарпе будет выглядеть так:

код алгоритма

static class Algo
{
public delegate void Operation<T>(T arg);
public static void ForEach<T>(Func<T> i, Operation<T> op)
{
T c = default(T);
do
{
c = i();
op(c);
}
while(c!=null);
}
}

а так использовать

Algo.ForEach<string>(System.Console.ReadLine, System.Console.WriteLine);

Но я в шарпе не очень разбираюсь, так что возможно проще можно сделать.


S_T_A_S_ пишет:
А еще я видел как перловики тупо брали справочник по С++, садились и писали сложный софт, который при запуске просто начинал работать 24*7 без утечек и падений.
Не поверю пока не увижу своими глазами. Или у нас разное понятие о сложности. Самый серьезный проект на C++ в котором я участвовал это более 500.000 строк кода, который писался больше 10 лет. Самое бизобидное на первый взгляд изменение может повлечь очень серьезные последствия. Причем может оказаться так, что код пройдет линт, ревью, QC и сломается черех полгода у одного кастомера.

Demon666 пишет:
Опытный программист – это не тот, кто знает один в идеале язык программирования и надееццо что за него компилятор найдет ошибки...
А тот, который знает не меньше пяти язык программирования в идеале(ASM в обязательном порядке)
И скриптовых языков не меньше десятка!

А что это за языки, которые должен знать опытный программист? В целях повышения образованности интересуюсь.
А вообще опытный программист, это программист с опытом. И не важно опыт этот состоял в использовании 20 языков или только одного. Тот же C++ можно учить годами и все равно находить новое использование конструкций языка.
По поводу асма: мне приходилось работать с очень опытными программистами на C++, которые не только не знали асма, но и считали что его знание вредно.

| Сообщение посчитали полезным: