Первое публичное выступление RTOS Systemicus + видео

image

Доброй ночи, хабр!

Думаю, что пришло время выложить первое видео и первую информацию о своей операционной системе, полностью написанной на flat assembler. Знаю, что уже много написано и сделано подобного, но думаю, что любителям данной темы это будет немного интересно.



Итак, тестирую всё это дело на QEMU c 48-ю мегабайтами оперативной памяти, но вся система удачно работает и на 8-и мегабайтах (включая графическую оболочку). Так же малы требования и к жесткому диску — само ядро занимает 64 килобайта (в действительности 20-24 килобайт, но из-за специфики моей файловой системы я забиваю остальное пространство нулями до 64кб.).
К необходимым файлам также принадлежит 4 библиотеки, такие как user32.dll, kernel32.dll и omfs3.dll (есть также network.dll, но пока сеть я забросил...). Также, необходимо присутствие двух шрифтов — для терминала и графики. + программа-терминал и программа графического окружения.

Сразу оговорюсь. Все программы компилируются в формат Windows PE GUI и PE console. Т.е. их можно запускать и на Windows, единственная загвоздка — формат моих dll несовместим с форматом Windows DLL. Из этого вытекает, что можно дописать аналогичные библиотеки под Windows (с теми же функциями) и все программы можно портировать на Windows. Аналогично, если написать библиотеки (точнее переписать) под Systemicus то программы Windows могут работать на моей ОС. Кстати, пробы были, в основном только с функциями MessageBox и др. мелочами. Но не в этом суть.

Следующим моментом является использование своей ФС — OMFS-3. Отличительной чертой ее есть встроенная система сквозного шифрования (ГОСТ+RC6 в связке с ГОСТ 34.11-2012 Стрибог. Всё тоже на assembler). Причем, при формировании загрузочного образа системные файлы не зашифрованы, но после любой операции (например, копирование файла) конечный файл уже шифруется. Это не ограничение ФС, просто при сборке загрузочного образа даже на макросе fasm очень сложно будет во время компиляции зашифровать эти данные. Т.к. вся логика и функционал забиты в omfs3.dll, то планирую позже сделать что-то наподобе LeanfsGUI, но для OMFS3.

Из самого необходимого, что я намерен сделать в ближайшем будущем — это RealMode Int, оптимизацию рабочего стола (пока есть проблемы со скоростью, я еще не оптимизировал его код, т.к. закончил его буквально вчера), портирование fasm на Systemicus (+ несколько других приложений), поддержку int 0x21 (минимум — чтоб запускать какой-нибудь файловы менеджер и несколько игр под DOS). В будущем хочу всё-таки добавить в свои DLL поддержку минимальных функций WinAPI, не столько для совместимости с Windows, сколько из соображений экономии — дабы не переписывать код некоторых приложений. Слава Богу, наработки есть, пару простых консольных Windows-приложений уже запускал на Systemicus.

Вот. Если это кому-то интересно, то буду писать дальше о прогрессе в разработке + буду выкладывать самые интересные пройденные трудности в реализации некоторых вещей. Для примера, реализация поддержки PE+DLL очень помогла мне понять принципы работы этой связки в Windows, что помогло мне написать для нее неплохой PE-упаковщик ;-)

В завершение — скринкаст работы…

Only registered users can participate in poll. Log in, please.

Продолжать публиковать информацию об этой ОС?

Share post

Similar posts

Comments 53

    +1
    Как-то непонятно, откуда настолько ощутимые тормоза при выводе пары окошек в GUI.
    Хоть тут и эмуляция через QEMU, но еще во времена разработки под DOS у меня получалось делать более сложные и при этом шустрые интерфейсы на VESA.
      0
      ну про один баг могу сказать, есть ошибка, что обновляется рабочий стол не один раз, а дважды при перерисовке окна. баг есть, решу его вместе с оптимизациями. (например, не перерисовывать весь фон, а только фон под обновляемыми окнами + оптимизация самого кода). MMX и др. инструкции не использую, т.к. хочу совместимости с i486
        +2
        Ну не объясняет это такие тормоза. Имхо у вас что-то с самим алгоритмом формирование изображения «не того»…

        На 386 SX (25Mhz) и карточкой S3 Virge не было таких тормозов при работе с графикой.

        >только фон под обновляемыми окнами
        есть такое слово «двойная буферизация», у вас с этим явно какая-то беда…
          0
          Двойная буферизация не для увеличения скорости отрисовки, а для красоты. Изображение сначала формируется в памяти, а потом быстро выдаётся на экран. Такой механизм не решает проблему скорости формирования изображения — только скорость отрисовки. А при недостатке ресурсов памяти двойная буферизация может и тормозить.
            0
            >а для красоты
            Вы видели как отрисовываются окна у автора? :) это как раз и есть отсутствие двойной буфферизации…

            >не для увеличения скорости отрисовки
            А вот это как раз зависит уже от того как происходит вывод изображения. Если автор сейчас использует попиксельный доступ к видео-памяти (а судя по картинки именно так он и делает), то двойная буфферизация как раз и увеличит быстродействие раз так в 100.

            >А при недостатке ресурсов памяти двойная буферизация может и тормозить.
            Вы ничего не путаете? Какой год на дворе? 6 мегабайт (1920x1080x24) под видео-буффер жалко???
              0
              Там же вся операционная система 8 Мег занимает, а тут ещё сравнимое пространство только под видеобуфер. На самом деле это не вопрос быстродействия самой ОС, а вопрос работы с видеокартой. Наверняка в большинстве видеокарт есть поддержка механизма двойной буферизации — если его задействовать, то и скорость увеличиться в разы. Впрочем, альфа-версия ровно для этого и выпускается, чтобы найти узкие места.
                0
                Ну значит и графику надо делать 320x200x8, и будет всего 64кб :D

                >Наверняка в большинстве видеокарт есть поддержка механизма двойной буферизации
                Ну и вот это выдаёт в вас «эксперта» в данной области. Без обид, но иногда лучше промолчать…
                  –1
                  если делать 320x200x8, то лучше вообще ее не делать)))
            0
            двойная буферизация есть. но действительно это альфа и не было никакой оптимизации. т.е. работает и хорошо. а оптимизации — это в след. версиях. более того, графика — это второстепенно, сделал ее за 2 дня, основное это внутри, в текстовом режиме.
          0
          так и думал) нашел причину основную тормозов. Планировщик. У меня же сейчас самый простой планировщик, т.е. обычная очередь, соотв. два из трех процессов просто впустую забивают время.

          Сделал функцию, которая отдает управление планировщику, если ничего приложение не делает. Вобщем, скорость отрисовки поднялась оооочень заметно, я бы сказал раза в 3.

          Хотя доделать сам вывод графики и сам алгоритм тоже нужно.
          +3
          Расскажите лучше, что используете под капотом (принципы), а также главное: зачем? (и почему копируете windows)
          С вашими нынешними умениями, вам бы помочь KolibriOS в написании всего и вся.
            +3
            Kolibri мне напоминает линукс — слишком мусорное ядро, в которое много лишнего натолкали. Хотя система интересная, всегда за ней слежу. Принцип — иду к микро или наноядру. Вначале это было сложно, но по мере развития стало возможны убирать из ядра ненужные функции, скажем в первом варианте ядро было под 50 килобайт, сейчас много вынес в dll и осталось в последней версии 21 Кб, хочу довести эту цифру до 16 максимум, т.е. только прерывания некоторые и планировщик.

            Windows. Для удобства. Вначале исполняемые файлы у меня были ELF, но потом что-то меня в них не устроило (уже не помню что именно) и перешел на PE32. Для чего нужна совместимость: хочу в будущем переносить некоторые простые программы без перекомпиляции (особенно, если там закрытый код) на свою систему. Ну а вообще, это побочный продукт. Просто мне нужны были PE и DLL, а эта возможность сама вылилась как следствие.

            Про принципы. Хочу)) как можно более компактный код, минимальные требования и полное шифрование диска (потом и трафик сети может быть). + RTOS. Пока использую простую очередь процессов, потом будет более сложная реализация, но для этого надо поэксперементировать с точным таймером, чтоб действительно обеспечить гарантированность выделения квантов времени.

            Ну и самое главное, это хобби. Вместо сериалов и игр)
              +4
              Сейчас в Колибри из ядра много вытаскивается в библиотеки. А по поводу микроядро/монолит, в частности: board.kolibrios.org/viewtopic.php?f=1&t=2661&p=56769#p56769
                0
                А что вы думаете насчет ReactOS? Использовали ли вы исходники ReactOS в качестве источника информации о работе Windows-подобной ОС внутри? Не участвовали ли когда-нибудь в развитии проекта ReactOS?
                  0
                  нет, иходники ниоткуда не тырил))) подсматривал иногда исхоники у колибри, но не копировал, а всё-равно писал заново. ReactOS вообще сорцы не смотрел, хотя каждую сборку тестирую) жду 0.4))
                  0
                  А вы можете ткнуть пальцем, где у нас там в ядре мусор?
                    +1
                    я не хотел обидеть, не подумайте чего, сам вдохновляюсь наработками Колибри.
                    Я имею ввиду не мусор больше, а то что многое запихнуто в ядро, в частности оболочка. (возможно, сейчас уже не так, давно не смотрел исходники, но раньше в колибри множество графики выводилось через прерывания, к примеру ну и т.п.)

                    Я не говорю, что это плохо, ибо линукс так тоже работает, я говорю о разных концепциях, как Minix vs Linux

                    Простите за слово «мусор». Перефразирую, ядро сильно нагромождено.
                      +1
                      Здесь Вы правы — в ядре действительно много всего, что можно вынести в драйверы, но это же не мусор и не лишнее :-)
                0
                А что с dll не так, откуда несовместимость?
                  0
                  исключительно от лени (нет, т.е. от недостатка времени, так красивее звучит) )
                  +5
                  Нервы у вас стальные, и стрессоустойчивость разиватая по всей видимости. Снимаю шляпу, у меня бы, как и большинства на такое не хватило сил.
                    +4
                    Системикус? О_о Вас Артемий Татьянович покусал?
                      +4
                      А кто покусал Артемия? Древние римляне что ли?
                        +3
                        Куртуазные маньеристы.
                      +3
                      Разработка коммерческая или просто закрытая?
                        +1
                        Бу! Это же не UNIX, какая разница?
                          0
                          пока закрытая, как будет бета — выложу код, просто там пока всё сыровато, стыдно немного такой код вылаживать)
                            –1
                            И когда же ожидается бета-версия?
                              0
                              хотелось бы к концу лета успеть всё…
                          –1
                          Было бы очень интересно увидеть поддержку команд на русском языке.
                            0
                            хоть на китайском) тут всё сделано по типу (на псевдокоде) if (crc32(command)) == 0xblablabla => execute
                            +4
                            Хорошее название на первом скриншоте. Тянет на очередной скандал :)
                            А так конечно круто, респект.
                              +1
                              А почему в заголовке фигурирует RTOS, а дальше по тексту об этом ни слова? )
                                –1
                                Полагаю что RTOS = Real-Time Operating System. И о ней как раз вся статья :)
                                  +4
                                  Вот как раз о Real-Time в тексте нет ни слова.
                                    +1
                                    Да, действительно. А очень зря, что нет ни слова. Интересно, какое гарантированное время отклика, например.
                                +3
                                А с какой целью разработка ведется на ассемблере, а не на другом языке с минимальным использованием ассемблера?
                                  0
                                  на любом друго языке (и компиляторе) нет возможности контроллировать и точно знать каждую команду, которую выполнит процессор. особенно компиляторы грешат со стеком, тогда как вручную большинство переменных можно запихнуть в регистры и работать с ними…
                                    +2
                                    А действительно ли это необходимо? Особенно учитывая стоимость разработки и поддержки кода. И портируемость на другие платформы.
                                      0
                                      портировать достаточно легко, если изначально задаться такой целью, т.е. изначально предопределить что-то типа

                                      x86:
                                      reg1 = eax
                                      reg2 = ebx
                                      x64:
                                      reg1 = rax


                                      + зависимый код писать отдельно для платформ.

                                      но нужно ли это. вон линукс портируется на многие платформы, а используются по сути 2 с половиной — x86 (+64) и ARM…
                                        +1
                                        Вы не правы насчет линукса. Совсем-совсем мертвые платформы из него выпиливают, а так то он на куче всяких архитектур действительно используется.
                                          0
                                          нет-нет, не поймите неправильно. такая система, как линукс — это отлично что она портируется на многие платформы. Ей положено))

                                          но если говорить про маленькие проекты — то так ли это необходимо, вот в чем вопрос…
                                            0
                                            Как раз именно RTOS как правило и нужен на различных «маленьких проектах», нежели на x86.
                                          +1
                                          Я все же думаю, что с подобными макросами ассемблерный код все равно останется непортируемым. В лучшем случае вы сможете портировать часть кода, но при этом он значительно потеряет в эффективности, так как на каждом процессоре есть свои хитрые способы эффективно решать те или иные задачи.

                                          В то же время, учитывая, что фирма Intel продвигает архитектуру x86 в очень разные ниши, в том числе встраиваемые ЭВМ, ваша разработка имеет некоторую перспективу.
                                        +1
                                        Вы знаете, в компиляторах задача распихать все что можно по регистрам занимает нетривиальный кусок кода, потому что это сложно. И в большинстве случаев компиляторы запихивают в регистры всё что можно.

                                        Как пример — у меня тут ~2000 строк кода на rust, со структурами, методами, локальными переменными в методах. В выходном листинге стек не используется вообще. И .rodata/.data пустые тоже. LLVM иногда похож на магию.
                                          0
                                          согласен, оптимизация сейчас отличная. ну, может быть, это вопрос менталитета, не могу я, когда за меня кто-то решит где быть той или иной команде, как будет выполнена та или иная инструкция и выдаст мне черный ящик, пусть даже и работающий отлично.
                                          вот такое старомодное восприятие))
                                            +1
                                            Я не могу сказать, что не разделяю такой взгляд, но последнее время я нахожу намного более эффективным просто контроллировать работу себя и компилятора. В основном я ковыряюсь с разными микрухами на С++ (а сейчас — и на rust), и писать высокоуровневые конструкции, а потом, при необходимости, проверять ассемблерный листинг таки занимает меньше времени чем писать на ассемблере всё.

                                            Естественно останутся неудачные места, например у моих программ в шапке вот такой кусок:
                                            00000042         movw       r0, #0x0
                                            00000046         movw       r1, #0x0
                                            0000004a         movt       r0, #0x1000
                                            0000004e         movt       r1, #0x1000
                                            00000052         cmp        r0, r1
                                            00000054         bhs        0x6a
                                            

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

                                            Кстати ассемблерный листинг читать «как есть» тоже сейчас не обязательно, благо неплохие дизассемблеры и декомпиляторы можно найти и не имея бюджета на всякий HexRays :-)
                                      +3
                                      Вы — практически последний из могикан, еще продолжающих писать большие системы целиком на ассемблере. Еще десяток лет — и этого исчезающего диалекта никто не поймет :(

                                      ...20 лет назад темой моего диплома был драйвер платы сигнального процессора TMS320, написанный на x86 ассемблере. На вводном занятии о «гайдлайнах» написания диплома я услышал предсказуемое «если ваш диплом — программа, вы должны обосновать выбор языка программирования», на что мой немного борзый вопрос был «если я собираюсь забить гвоздь, должен ли я аргументировать, что выбрал для этого молоток?». Преподаватель, читавший у нас курс по ОС, задумался лишь на секунду: «Если у Вас драйвер, вы можете не обосновывать, почему выбрали Ассемблер»

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

                                      Тем не менее, усилия приложены огромные, и главное, очевидна последовательность в достижении цели (на Ассемблере иначе нельзя — все развалится). Автору за проделанную работу — огромное личное уважение!

                                      Однако, если подобное качество проектирования использовать в разработке систем на языках высокого уровня, то масштаб полученной системы может быть воистине грандиозным — например, класса системы управления Вояджера и сопровождения его с Земли. Ведь умение программировать на Ассемблере — это отнюдь не знание инструкций, а скорее коренное понимание процессов в системе и необходимых для эффективной и надежной работы действий. И именно этот Ваш потенциал, как разработчика, можно использовать для создания гораздо более масштабных систем — надежных, компактных, быстрых.

                                      Это то, чего сейчас хронически не хватает в коммерческом IT, заселенном попсарями-недоучками — образно говоря, вместо ладно скроенных легких и надежных деревянных парусных кораблей, современная коммерческая IT- индустрия пачками создает тяжелые дырявые посудины, текущие памятью так, что с трудом способны с помощью многоядерного двигателя с дойти из порта в порт, с риском потонуть, несмотря на помпы (GC) и приставленных специалистов, готовых в любую минуту начать рейс сначала.

                                        0
                                        спасибо огромное) хотя у меня в коде сейчас тоже много проблем, но исправляю по-немногу…

                                        почему асм — просто с ним мне интересно, это как головоломка — всегда занятно. всегда есть стимул сделать код хоть на одну команду меньше, использовать только регистры, без обращения к памяти — чем не аркада))

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

                                        а если нужно написать под Windows\Linux что-то быстро и не напрягаясь — Delphi\Lazarus использую (только не бейте меня, любители C — у каждого своя религия))
                                          +1
                                          это как головоломка — всегда занятно
                                          у Ильфа и Петрова в Двенадцати стульях есть фраза о том, что параллельно существуют два мира — маленький и большой. Условно говоря, в маленьком мире делают головоломки, а в большом — прокладывают дороги и строят ГЭСы. И та, и другая работа требует длительных умственных усилий и высокой концентрации внимания — но масштаб результата оказывается несопоставим.

                                          Да, хорошо написанный ассемблерный код вызывает радость и уважение к создателю, но например, такое же уважение к создателю может вызывать и хорошо спроектированная ERP-система, причем просто при взгляде на блок-диаграмму (даже не на диаграмму классов, API, или сам код) — в последнем случае уровень обобщения скрывает не только регистры, но и архитектуры целиком ;)

                                            0
                                            В статье не написано, использовали ли вы защищенный режим? Я понимаю, что это подразумевается, но все же…
                                              0
                                              Можно предположить, что все работает в PM, раз автор использует PE32
                                                0
                                                да, защищенный режим и адресуется все 4Гб адресного пространства + странички. на 4Гб страничной адресации правда ушло много памяти в оперативке ( 4 мегабайта!!! :( ), но вещь нужная, т.к. при использовании VESA в PM32 адресация верхних адресов необходима…

                                              Only users with full accounts can post comments. Log in, please.