изобретается ОСь

[arhimed486]

Кто-то компьютеры собирает, а я проги пишу... на ассемблере. В основном занимаюсь управлением железом компьютера через BIOS и напрямую, на аппаратном уровне. Есть 2 своих примитивных операционки, но их лучше не показывать, слишком уж много багов, да и далеко не на всех компах они запускаются...
Покажу пару графических "фишек", достаточно распространенных, но все-же интересных, - "горящий огонь".
В архиве: fire - первый вариант, написан на TASM, всего 262 байта. Fire2 - улучшенный вариант поновее, написан на FASM, имеет несколько цветов, переключаются кнопками 1-8 (не на нумпаде), размер 630 байт. Выход - esc.

P.S. Для тех кто подумал, что я только на асме программировать умею - это не так.

[j2153]

Есть 2 своих примитивных операционки

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

[arhimed486]

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

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

[j2153]

написание и отладка ОС процесс не простой и времени много отнимает

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

2. Новая задача - встроенная защита от вредоносных программ.
Во времена ДОС, откуда ведет свой род и Винда, программист был чаще всего и пользователем своего компа. Так что было прямым абсурдом писать заведомо разрушительную программу.
Современная ДОС должна уже строиться на принципах отсутствия механизма вторжений. Например она не должна позволять изменять исполняемые файлы без прямого разрешения пользователя, не должна иметь механизмов одной программе перехватывать чего-нибудь у другой, или влезать в чужую память.

Как Ваше мнение обо всем выше сказанном?

И еще вопрос: какую модель реализации многозадачности Вы применили?

[arhimed486]

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

Разделяемые динамические библиотеки нужны, так как программы ведь в ОЗУ грузятся. Представьте себе, если каждая прога в своем составе будет иметь половину ОСи, загрузим две-три таких и 2-х гигов ОЗУ как не бывало, а затем будет использоваться файл подкачки, а диск работает медленно. И к томуже кроме кода программ необходимо еще и данные хранить.

Пользовательский интерфейс ОС - это по сути привилегированная прога с функциями файлового менеджера. Вот ее-то можно модифицировать, выпускать новые версии и т.д., и т.п.
Что остается на долю ОС? - только ядро, обеспечивающее многозадачность, и комплекс драйверов. Всё.

Согласен.

Многопользовательский режим с удешевлением компьютеров отомрет, как коммунальные квартиры. (Если уже не отмер).

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

Современная ДОС должна уже строиться на принципах отсутствия механизма вторжений. Например она не должна позволять изменять исполняемые файлы без прямого разрешения пользователя, не должна иметь механизмов одной программе перехватывать чего-нибудь у другой, или влезать в чужую память.

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

И еще вопрос: какую модель реализации многозадачности Вы применили?

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

[j2153]

Продолжение диалога, начатого в другой теме.

Разделяемые динамические библиотеки нужны, так как программы ведь в ОЗУ грузятся. Представьте себе, если каждая прога в своем составе будет иметь половину ОСи, загрузим две-три таких и 2-х гигов ОЗУ как не бывало, а затем будет использоваться файл подкачки, а диск работает медленно. И к томуже кроме кода программ необходимо еще и данные хранить.

Вот объясните мне, я никогда не понимал. Что можно программировать в ГИГАБАЙТАХ кода? Я понимаю - данные, их можно накопить и 100 гиг (видеофильмы). Но машинный код, где каждые 3 - 4 байта - уже команда, какие настолько сложные операции могут потребовать столько?..
Во времена ДОС я писал прогу с оконным интерфейсом в тонкой графике. (Не на ассемблере, но близкий к тому компилятор). Все рамочки, менюшки, всё программировалось в ручную кодом.
Окончательный экзешник занял 150 кБайт. Не было реализовано только перемещение окон мышкой (не понадобилось).
Я понимаю, что современный GUI сложнее, но не в 1000 же раз?

Сомневаюсь, что он отомрет целиком. Например на компьютерах где-нибудь в университете или в библиотеке

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

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

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

Относительно логического адресного пространства.
Прошу меня извинить, если пишу деЦЦкий лепет. Я не позиционирую себя программером, так что мне будет простительно.
Я вот думаю: нельзя ли выделить каждой запущенной программе собственную виртуальную машину?
Сразу возникает вопрос: должен ли ее машинный код быть тождественным коду процессора?
Если нет - то придется писать ВЕСЬ софт заново, потому что существующий работать не сможет. Подобное - неподъемный гимор.
НО! Существует например кроссплатформенный язык Ява, на котором имеется софта изрядно.
Не заставить ли виртуальную машину обрабатывать инструкции этого языка? (ну или не Ява, а, там, Дельфи, Бейсик, Си, PHP... Что лучше подойдет.)
Тогда механизм многозадачности превращается фактически в многозадачный интерпретатор выбранного языка.
Что Вы думаете относительно такого варианта?

[Falconist]

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

[arhimed486]

j2153, спасибо, что заинтересовались моей ОСью.

Вот объясните мне, я никогда не понимал. Что можно программировать в ГИГАБАЙТАХ кода? Я понимаю - данные, их можно накопить и 100 гиг (видеофильмы). Но машинный код, где каждые 3 - 4 байта - уже команда, какие настолько сложные операции могут потребовать столько?..

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

Я вот думаю: нельзя ли выделить каждой запущенной программе собственную виртуальную машину?
Сразу возникает вопрос: должен ли ее машинный код быть тождественным коду процессора?
Если нет - то придется писать ВЕСЬ софт заново, потому что существующий работать не сможет. Подобное - неподъемный гимор.

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

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

Об использовании кроссплатформенного языка я тоже думал, но до этого еще далеко, так как вначале необходимо чтобы работали "родные" программы, написанные и скомпилированные под данную ОСь. А потом можно и JVM попробовать реализовать, что-бы программы на Яве можно было запускать.

[TEHb]

Следующий шаг, необходимый для продвижения этой ОС - портировать под неё GCC Toolchain. Но для этого ой как много чего нужно сделать.
А вообще написание новых ОС нужно только для академических проектов. Пока её не будет поддерживать значительная часть девелоперов - она мертва. Посмотрите на ту же самую Haiku (в девичестве BeOS).

[arhimed486]

А вообще написание новых ОС нужно только для академических проектов. Пока её не будет поддерживать значительная часть девелоперов - она мертва.

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