OSDev

В связи с непредвиденными обстоятельствами, разработка была прекращена месяца 3 назад. И вот, Феникс ОС возрождается из п̶е̶п̶л̶а̶ исходников с Dropbox.
Как и предсказывал iz56, Концепт ОС был довольно сильно переработан, изменены инструменты, изменены планы. Немного подробнее:

1. ОС теперь полностью 64-битная. i386 и ARM планируется fork-нуть после первого релиза.
2. Теперь используется только GNU C++ (и совсем чуть-чуть FASM для начальной загрузки, впоследствии перепишу на GNU Assembler).
3. ОС будет бинарно совместима с приложениями Windows. Про драйверную модель пока что не уверен, но приложения будут, и будут нативно.
4. ОС всё ещё имеет основным направлением Web, будет поддержка HTML5/CSS3, приложения можно будет писать прямо на нём.
5. Графический интерфейс ОС планируется тайловый. После того, как поюзал Windows 8 и awesome, понял, насколько оно удобно.
6. С версии 0.1 (которая будет сразу после доработки загрузчика, драйвера VESA видео и оконного менеджера) код будет выложен на github, куда каждый желающий сможет делать pull request, чем и помогать в разработке.
7. Будет версия без оконного менеджера. Вообще, будет возможность собрать систему "под себя" при помощи редактора модулей.

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]

Чуть-чуть подправил Ваше сообщение: одну ошибку исправил (впоследствии), и дописал, что интерфейс -- графический (ибо сам не сразу понял; для меня интерфейс применительно к ОС -- это API, а не её морда лица, которую пользователь видит).

Поддержка приложений Винды означает фактически, что с точки зрения прикладного программиста эта система -- Винда На самом деле, несмотря на кучу недостатков, из распространённых ОС её API самый вменяемый, поэтому, если уж копировать, то точно лучше его, а не всякие там POSIX. Правда, и работы много больше предстоит.

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

Вот п. 4 Вашей программы (основное направление -- веб) мне кажется сомнительным. Дело в том, что, если чётко отделять мух от котлет, никаких "веб-ориентированных" осей в природе нет и быть не может. Любой браузер и прочее, связанное с вебом, -- это всего лишь прикладные программы, способные успешно работать на любой ОС, обеспечивающей минимальную поддержку (грубо говоря, поддерживающей клаву, мышь, графический дисплей и TCP/IP). Т.е. лично я бы чётко разделил: вот здесь -- ОС (ядро, драйверы, системные утилиты), вот здесь -- средства её разработки, а вот здесь -- вся прикладуха, в т.ч. "веб-ориентированная".

В значительной степени сказанное про п. 4 относится и к п. 5. Самой системе же пофиг, как она выглядит с точки зрения пользователя, и отнюдь не рабочий стол является самым сложным и важным компонентом системы, хотя и является её "лицом".

Естественно, я не согласился бы и с п. 2: писать что-либо сложней ХеллоВорлда на Си и всех его производных -- преступление против человечества Но тут уж каждый выбирает для себя сам.

Ну а в остальном -- желаю удачи. Надеюсь, что Ваша система не помрёт на ранних стадиях и будет более вменяемой, чем 99% существующих осей.

P.S. Ирония судьбы: и первые версии макинтошевской оси, и Вындовз-1 имели именно тайловый интерфейс: не было там перекрывающихся окон.

Я отвечу, пожалуй, в том порядке, в котором будет проще осмыслять ответы:

В этой части я вдохновлён Metro-приложениями Windows 8. HTML5+CSS3 поддерживаются прямо в системе, а JS API позволяет получать доступ к файлам/папкам/другим функциям системы. Одновременно достигается абстрагирование от типа процессора (всё равно, х32, х64, да хоть ARM) и прочих нюансов: HTML - он и есть HTML.

С точки зрения программиста я всё же оставлю HTML5 как основное средство разработки. Хочет Windows - пожалуйста, не запрещено, добавляй модуль поддержки Win-программ и юзай тот же Delphi/CBuilder/что_хочешь, и тут же и тестируй, как оно вливается в интерфейс.

Тут, опять же, основным будет всё же собственный, модульный интерфейс ОС. А поддержку Win-драйверов можно попытаться сделать через какой-нибудь wrapper. Опять же, если этого добиться, можно пойти дальше - использование x32-драйверов на x64 или ARM-based системе. Решается проблема старого железа.
Точно так же, через wrapper, можно и linux-драйвера цеплять. Модульность позволит творить практически что угодно

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

Большой процент кода ядра Linux написан на C. И я не заметил, чтобы это кто-то осуждал. Напротив - вижу скорость работы, которую без угрызений совести можно назвать высокой, и вижу достаточно понятный код (да, я и туда залезал). Компилятор с правильными флагами генерирует довольно оптимизированный и правильный машкод, да.

Знаю об этом Да, возможно, потом появятся люди, которые напишут альтернативный WM для ОСи, но я, пока что, не нашёл ничего лучше тайлов. Серьёзно, это наиболее оптимальное использование пространства. Например, сейчас у меня на ноутбуке открыты редактор кода, файловый браузер, консоль и калькулятор (конечно для dec/bin/hex). Самое оно

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]

А я наоборот - очень советую. Причем не стОит ограничивать себя одним компилятором. Надо писать так, чтобы система компилировалась несколькими в том числе и старыми (тогда с переносом в том числе и на устаревшее оборудование проблем не будет). Я например пишу на С++. Проверяю несколькими, самый старый из которых - 1998 года. Соответственно все особенности нового стандарта - за бортом. Мало того, что сам код практически самодокументирующийся, так ещё на этом языке можно естественным образом выразить логические отношения между объектами ОС. Например то что объект файла и объект анонимной памяти наследуется от объекта памяти и т.о. VMM через интерфейс объекта памяти ими может манипулировать (например при обработке ошибки страницы) не вдаваяь в подробности что за объект, которым он управляет. Естественно, при таком подходе должен быть грамотный HAL (в солярке или bsd - pmap), который являсь по набору функций достаточно общим для многих архитектур в достаточной мере скрывает особенности работы с оборудованием. Вот он - уже может (но не обязан) быть написан на асемблере т.к. не переносим по определению (но в большинстве операционок и он кстати написан на С). С HALом у меня есть проблемы т.к. банально не хватает кругозора работы с разными процессорами и знания их особенностей. Главный после интеловых (32 и 64 бита) это конечно ARM, благо, там уже SMP появился.
Я писал достаточно на асме чтобы понять, что для любой особенно длительной разработки - это тупик. БОльший прирост скорости исполнения можно получить грамотным использованием кэша процессора чем высчитыванием количества тактов в каждой инструкции и блоке кода. Уж о том, что грамотный код может компилироватся одновременно и в 32-битную и 64-битную версии - я и не вспоминаю. Это само собой разумеется. Это не начало холивара а чистое ИМХО, но мне не известны причины по которым асм был-бы лучше чем ЯВУ кроме необходимости программировать оборудование (но это несколько небольших вставок). Про скорость - писал выше, объем - в настоящее время уже не критичен. Объем ИМХО - уже в середине 90-х мало кого интересовал на интеловых платформах.

Вообще-то я говорил против Си не в пользу ассемблера, а в пользу паскалеподобных языков (например, Ады, входящей в состав GCC). Хотя, если поставить меня перед выбором "Си или ассемблер", выберу второй: Си куда больше провоцирует на совершение тупых, но трудных в обнаружении ошибок, является малочитабельным и по-любому проигрывает в эффективности даже без всякого "подсчёта тактов". Кроме того, лично по моему опыту могу судить, что примерно 3/4 всего затрачиваемого времени уходит на проектирование, написание комментариев и документирование -- т.е. на вещи, вообще не связанные с используемым языком; соответственно, использование ассемблера вместо даже хорошего ЯВУ (той же Ады) даёт не такой уж большой проигрыш по времени. Но всё уже лирика, а в контексте данной темы -- ещё и злостный оффтоп

Для серверов, гоняющих файлы и странички по сети я бы сказал не важно какая ОС запросила инфу, эта ОС должна знать TCP\IP, HTML, NetFileS и т.д.. Сам интерфейс у системы как я понял будет как один только браузер в котором будет организована вся работа, это возможно, и видео смотреть и аудио слушать, текст можно печатать сделать, кисточкой рисовать. От писания драйверов и всё остальное ни кто не освобождал.

Вероятно, проще застрелиться, чем повторять столь монстроидальный (по размерам, не по качеству!) АПИ. Это – игра в догонялки, к тому же на много лет. Кроме того, предвижу некоторые лицензионные трения. Так, в соответствии с доками МС, формат исполняемых файлов PE32/PE64 может быть использован только для майкрософтовских операционок. Правда в случае ГНУсных операционок они пока что закрывают на это глаза.

Мне непонятно, – если копируется программный АПИ существующей системы, то чем PhoenixOS лучше ReactOS?

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


Должен согласиться с SII. С – плохой язык. Правда ADA и паскалеподобные языки ещё хуже. Кроме того, при любом раскладе лично меня сильно напрягает привязка к конкретному компилятору. Уж GNU – точно не лучшие компиляторы. На сегодняшний день я вообще в серьёзном затруднении, как в выборе языка, так и в выборе компилятора. Больше склоняюсь к мысли, что нужно создавать новый язык программирования, с синтаксисом, похожим на С/С++, но несовместимым с ними. Увы, создание компилятора с хорошего языка программирования – задача, сопоставимая по сложности с написанием ОС.


К сожалению, это – скорость создания новых глюков, а не хорошего продукта. С устарел, как и Posix, и для крупных проектов подходит плохо. Уж лучше бы использовали C++. С в ядре используется не потому что хорош, а потому что требуется совместимость по вызовам и по структурам со всем остальным кодом. В данном случае совместимость – такой же тормоз прогресса.

Моё резюме: к большому сожалению, я пока не вижу перспектив у данной ОС.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Компилятор функционального уровня можно за две недели написать. Там сложного ничего нет. Кроме теории, которую читать не следует. Если вы что-то задумаете более сложное, то да. Но в целом оно будет работать. Вы постепенно будете его развивать до уровня который вам нужен.

А можно готовую сборку со всеми драйверами? А то мне что бы скачать надо 5 минут чтобы изучить что мне надо потребуется 30 минут. А когда будет известно будет надо 6 минут что бы выбрать, то что мне нужно.

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

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]

Теперь PhoeniX OS на github.
Довольно обильно переделан код.
Было долгое затишье - опять недостаточно времени...

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]