kbrd dd 1024 ; keyboard buffer size = 1kb
db '/dev/keyboard',0 ; device name
kbrdbuf db 1024 dub(?) ; keyboard mirror
.code
lea esi,kbrd ; указатель на описание устройства
lea edi,kbrdbuf ; описываем буффер как клавиатуру
lock mov [edi],esi ; "подключаем" клавиатуру
L1: cmp byte ptr[kbrdbuf],0x1B ; Ожидаем клавишу Esc
jne L1
lock mov byte ptr[edi],0 ; "отключаем" клавиатуру от нашей задачи
Написание операционной системы
Возникла необходимость написать свою Операционку которая сможет работать с видео и звуковыми устройствами... в связи с этим возникло много вопросов... и ли даже догадок к которым я хочу услышать коментарии...
1 вопрос свяязан с самой структурой исполняемго файла (не нашёл книжки в которой рассматривалось бы что компилятор записывает в исполняемый файл), в винде это exe/com в linux просто файл так вот что именно компилятор заносит в исполняемый файл? я так понимаю там тупо команды переведённые в 1001101... ? если это так то второй вопрос отпадает сам собой... в чём разница между exe и исполняемыми файлами линухи? (предполагаю что только в используемой API)
2 я читал статьи по написанию операционок и там мы сначала компилируем в иcполняемый файл причём не важно под linux/win и записываем в boot сектр далее как я понимаю bios читает boot сектр и тупо выполняет его содержимое но если между исполняемыми файлами lin/win есть разница то как он вообще это делает?
3 что есть ФАЙЛОВАЯ СИСТЕМА? т е я не спащиваю как она устроена (понятно что это способ распределения и хранения информации о используемой памяти) мне интересно другое - что этим занимается?
я так понял что это некоторый моуль операционки который при команде создания файла резервирует необходимое количество ячеек на жёчтком диске записывает в спец таблицу номер первой ячейки(понятно что эти действия зависят от модели ФС) и записывает данные, так?
Пока что всё...коментарии...
1 вопрос свяязан с самой структурой исполняемго файла (не нашёл книжки в которой рассматривалось бы что компилятор записывает в исполняемый файл), в винде это exe/com в linux просто файл так вот что именно компилятор заносит в исполняемый файл? я так понимаю там тупо команды переведённые в 1001101... ? если это так то второй вопрос отпадает сам собой... в чём разница между exe и исполняемыми файлами линухи? (предполагаю что только в используемой API)
2 я читал статьи по написанию операционок и там мы сначала компилируем в иcполняемый файл причём не важно под linux/win и записываем в boot сектр далее как я понимаю bios читает boot сектр и тупо выполняет его содержимое но если между исполняемыми файлами lin/win есть разница то как он вообще это делает?
3 что есть ФАЙЛОВАЯ СИСТЕМА? т е я не спащиваю как она устроена (понятно что это способ распределения и хранения информации о используемой памяти) мне интересно другое - что этим занимается?
я так понял что это некоторый моуль операционки который при команде создания файла резервирует необходимое количество ячеек на жёчтком диске записывает в спец таблицу номер первой ячейки(понятно что эти действия зависят от модели ФС) и записывает данные, так?
Пока что всё...коментарии...
Ищо один...
Цитата: logree
в linux просто файл
Это не просто файл. Да и COM/EXE мало о чем говорит. COM - набор команд процессора с первого до последнего байта (исключая данные программы, конечно). EXE содержит в себе PE заголовок (ищите по запросу "PE формат"). Исполняемые файлы Linux - это ELF файлы - тоже формат исполняемого файла, но я в нём как-то не ковырялся, потому сказать из чего он сделан не могу.
Цитата:
2 я читал статьи по написанию операционок и там мы сначала компилируем в иcполняемый файл причём не важно под linux/win и записываем в boot сектр далее как я понимаю bios читает boot сектр и тупо выполняет его содержимое но если между исполняемыми файлами lin/win есть разница то как он вообще это делает?
Программа в boot секторе не содержит заголовка. Это в своем роде тоже COM программа, но со своими нюансами (читайте литературу, благо еще предостаточно).
Цитата:
я так понял что это некоторый моуль операционки который при команде создания файла резервирует необходимое количество ячеек на жёчтком диске записывает в спец таблицу номер первой ячейки(понятно что эти действия зависят от модели ФС) и записывает данные, так?
Типа того.
Читайте литературу по ассемблеру и классику в виде "Современных операционных систем" под авторством Таненбаума. Да и сайт lowlevel.ru оказался неожиданно живой - там по сабжу материала выше крыши.
hardcase, зря иронизируете: люди в ходе таких "исследований" хоть что-то понимать начинают
Цитата: dreamer.mas
hardcase, зря иронизируете: люди в ходе таких "исследований" хоть что-то понимать начинают
Я просто уже устал "посылать на Олиферов" (книга Сетевые операционные системы).
Цитата: logree
Возникла необходимость написать свою Операционку...
А у Вас наброски есть? Теория? Дело в том, что у меня уже давно есть теория новой ОС без API вообще на любом уровне, где ОС просто нивидима приложениям. Я начал с того, что написал простой x86-эмулятор. Но, как оказалось, теория пока не выдерживает практики. А чтобы её развить, нужен хоть какой-то коллектив, для разработки хотя бы начальных классов данных, структур и типов, чтобы иметь хоть какую-то базу стандартов. В ОС у меня нету файловой системы и понятия "файл". Всё построенно на уровне микро-сетевой организации клиент-сервер и теоритически более-менее складно. А практически, как уже сказал, проблема со стандартами и т.д.
Пробная демо-модель работает пока с "левыми" именами каналов, типо /dev/mouse или /dev/opengl, что слишком по линуксовски.
Был бы рад объединению наших усилий... ;)
[QUOTE=Vertecs]Дело в том, что у меня уже давно есть теория новой ОС без API вообще на любом уровне, где ОС просто нивидима приложениям.[/QUOTE]А в чём тогда её смысел?
Цитата: Der Meister
А в чём тогда её смысел?
Хы. На уровне DOS клавиатура через порт 0x60 тоже доступно без всяких API, но разве DOS от этого теряла смысл в своё время? ;)
Я не хочу сказать, что в моей ОС всё как в DOS. Просто все ресурсы системы доступны не через CALL (как в Windows, например), и не через INT (как в DOS или MenuetOS). И при этом не через порты тоже. Просто имеется специальный заголовок, где та или иная область памяти приложения объявляется как системное окно. Т.е. Объявляем, например, массив как /dev/keyboard размером в 3Гб, и он системой воспринимает как буффер клавиатуры. Причём эти 3Гб может заполнять как пользователь непосредственно у данного компьютера, так и сервер на другом краю планеты. Тут, как видите, API никакое не нужно. А приложение объявляет массив с помощью исключения, используя префикс LOCK + инструкция с адресом начала массива. Тем самым системе "сигнал" подан, но приложение использовало просто префикс блокировки шины, будто ОС нету вовсе, но есть "умный контроллер шины". Кстати, в виртуальных машинах такой принцип и работает, причём эмулятор тоже невидим. Моя же цель в том, чтобы ОС работала как 100% виртуальная машина, но все порты и т.д. не работали как эмуляция реальных. Понимаете? Получаем 100% гибкую конфигурацию компьютера, но в отличии от существующих, она не эмулятор, а самостоятельная ОС.
По идее, рабочая "голая" такая ОС будет весит несколько сот кб. Единственная её обязанность - распределение машинного времени между задачи с защитой памяти и обеспечения возможности назначения сегментов памяти конкретных задач конкретным сервисам...
Проблема лишь в следующем:
Код:
Проблема в том, что заголовок клавиатуры я "тупо" объявляю как файл /dev/keyboard на подобии как в линукс. Хотя, в системе это черновой вариант для начала. А серъёзно, нужно придумать более гибкие структуры для клавиатур, мышек, кошек, OpenGL и т.д. и т.п.
Проблема №1: Я не могу пока сам написать ядро для этой ОС;
Проблема №2: Структуры подключаемых устройств не разработаны;
Проблема №3: Готовые ядры, Linux или даже MeOS, нужно перерабатывать...
У вас, как раз-таки, наоборот получается, что вся операционка построена на понятии "файл". То есть, у вас файл - всё, что поддерживает произвольный и/или последовательный доступ к данным, а программы работают посредством чтения и записи в эти файлы.
Но здесь странная картина получается: жена вроде есть, продукты в холодильник она кладёт, но жрать себе готовишь исключительно сам. И всё остальное, чем жёны занимться должны - тоже... своими руками? :D
Но здесь странная картина получается: жена вроде есть, продукты в холодильник она кладёт, но жрать себе готовишь исключительно сам. И всё остальное, чем жёны занимться должны - тоже... своими руками? :D
Цитата: Vertecs
...Просто имеется специальный заголовок, где та или иная область памяти приложения объявляется как системное окно. Т.е. Объявляем, например, массив как /dev/keyboard размером в 3Гб, и он системой воспринимает как буффер клавиатуры. ...
кем объявляется ?
где объявляется ?
как приложение узнает , что где-то что-то объявили ?
почему /dev/keyboard система должна воспринимать как буффер клавиатуры ?
откуда система знает какую область памяти надо объявлять как системное окно ?
что такое "системное окно" ?
Цитата: Vertecs
Дело в том, что у меня уже давно есть теория новой ОС без API вообще на любом уровне, где ОС просто нивидима приложениям.
Экзоядро штоле?
Цитата: hardcase
Я просто уже устал "посылать на Олиферов" (книга Сетевые операционные системы).
дык поражает когда человек, впервые столкнувшись с программированием пытается написать/изменить игровые движки, ОСи и т.д. поэтому и "ещё один" :)
Как-то раз к Моцарту обратился молодой человек, желавший стать композитором.
- Как написать симфонию? - спросил он.
- Но вы еще очень молоды для симфонии, ответил Моцарт, - почему бы не начать с чего-нибудь попроще, например с баллады?
- Но сами-то вы сочинили симфонию, когда вам было девять лет...
- Да, - согласился Моцарт. - Но я ни у кого не спрашивал, как это сделать...
- Как написать симфонию? - спросил он.
- Но вы еще очень молоды для симфонии, ответил Моцарт, - почему бы не начать с чего-нибудь попроще, например с баллады?
- Но сами-то вы сочинили симфонию, когда вам было девять лет...
- Да, - согласился Моцарт. - Но я ни у кого не спрашивал, как это сделать...
[QUOTE=koderAlex]кем объявляется ?
где объявляется ?
как приложение узнает , что где-то что-то объявили ?
почему /dev/keyboard система должна воспринимать как буффер клавиатуры ?
откуда система знает какую область памяти надо объявлять как системное окно ?[/QUOTE]Не, ну он же пример кода-то привёл :) Может быть, именно по такой схеме и не прокатит, но суть ясна: интерфейсов как таковых нет, но есть данные, которые можно отправлять и читать, а ещё иногда изменять произвольным образом. Например, в одину область кладём данные для шифровки, из другой достаём результат шифрования. Правильно? Такое приобретение могло бы показаться волшебным джином, если бы не было, в действительности, ненужной (точнее, не выдерживающей конкуренции) женой.
где объявляется ?
как приложение узнает , что где-то что-то объявили ?
почему /dev/keyboard система должна воспринимать как буффер клавиатуры ?
откуда система знает какую область памяти надо объявлять как системное окно ?[/QUOTE]Не, ну он же пример кода-то привёл :) Может быть, именно по такой схеме и не прокатит, но суть ясна: интерфейсов как таковых нет, но есть данные, которые можно отправлять и читать, а ещё иногда изменять произвольным образом. Например, в одину область кладём данные для шифровки, из другой достаём результат шифрования. Правильно? Такое приобретение могло бы показаться волшебным джином, если бы не было, в действительности, ненужной (точнее, не выдерживающей конкуренции) женой.
Судя по вопросам автора топика могу сказать, что операционку в ближайшее время он не сделает. Но исходя из сделанных акцентов, можно попробовать реализовать самозагружаемую программу, которая могла бы работать с аудио/видео, т.е. позволяла бы сделать из компьютера мультимедийный проигрыватель. Эта задача тоже не из простых, но все-таки проще, чем озвученная, к тому же конечная цель значительно более конкретна, что должно упростить работу на этапе проектирования.
Цитата: Phantom-84
... самозагружаемую программу, которая могла бы работать с аудио/видео
Типичная игра под ДОС-ом + собственный загрузчик.
Цитата: Der Meister
Не, ну он же пример кода-то привёл :) Может быть, именно по такой схеме и не прокатит, но суть ясна: интерфейсов как таковых нет, но есть данные, которые можно отправлять и читать, а ещё иногда изменять произвольным образом. Например, в одину область кладём данные для шифровки, из другой достаём результат шифрования. Правильно? Такое приобретение могло бы показаться волшебным джином, если бы не было, в действительности, ненужной (точнее, не выдерживающей конкуренции) женой.
без разбора идеи я тоже могу привести намеренно испорченный код :)
интерфйейс у товарища есть - использование отладочный прерываний . только нафига это надо ? и быстродействие такой оси будет ужасным .
Цитата: hardcase
Типичная игра под ДОС-ом + собственный загрузчик.
Если он хочет декодировать mp3/jpeg/aac/ogg/mpeg4/h263 я думаю он этого еще очень-очень долго не сделает :)
А вообще hardcase прав. Редкостный бред спрашивать на форуме о том как написать операционку. Равносильно что спросить как написать программу. Все это имхо. И не для того ли придумали высшее образование, обсуждающееся в соседней ветке? :)
ПыСы. А я тож хочу написать операционку. Но не буду. Куда мне, если я даже в существующих не разобрался?
Кстати, концепцию такой ОС я начал разрабатывать 12 лет назад, ещё когда работал в DOS.
Цитата: Der Meister
У вас, как раз-таки, наоборот получается, что вся операционка построена на понятии "файл". То есть, у вас файл - всё, что поддерживает произвольный и/или последовательный доступ к данным, а программы работают посредством чтения и записи в эти файлы.
Но здесь странная картина получается: жена вроде есть, продукты в холодильник она кладёт, но жрать себе готовишь исключительно сам. И всё остальное, чем жёны занимться должны - тоже... своими руками?
Но здесь странная картина получается: жена вроде есть, продукты в холодильник она кладёт, но жрать себе готовишь исключительно сам. И всё остальное, чем жёны занимться должны - тоже... своими руками?
Ну, в DOS тоже можно открыть "файл" con и это будет перенаправлением с клавиатуры или на дисплей. Понятие "файл" в этом случае имеет широкий смысл. Сегмент 0xA000 тоже можно назвать зеркалом на файл видеоадаптера. От этого мало что меняется.
В моём же случае, в ОС отсутствует файл как таковое понятие. Т.е. не функций открытия/закрытия/чтения/записи файла. Тем более директорий или каталогов, дисковых устройств.
Цитата: koderAlex
кем объявляется ?
где объявляется ?
как приложение узнает , что где-то что-то объявили ?
почему /dev/keyboard система должна воспринимать как буффер клавиатуры ?
откуда система знает какую область памяти надо объявлять как системное окно ?
что такое "системное окно" ?
где объявляется ?
как приложение узнает , что где-то что-то объявили ?
почему /dev/keyboard система должна воспринимать как буффер клавиатуры ?
откуда система знает какую область памяти надо объявлять как системное окно ?
что такое "системное окно" ?
1) Приложением;
2) В памяти;
3) Не приложение, а ОС через исключение;
4) Я же сказал, я пока тупо взял "умненькие" линуксовые названица типо /dev/opengl, но протолы ничего общего не имеют с *nix. Только ссылки и всё;
5) Приложения явно указывает, тем самым закрывая часть этой области памяти от себя же, чтобы последующее обращение к тем ячейкам вызывало исключение и обрабатывалось нужным сервером;
6) Область памяти, разделяемое между приложением и конкретным сервером (графики/звука/консоли).
Цитата: Der Meister
Не, ну он же пример кода-то привёл :) Может быть, именно по такой схеме и не прокатит, но суть ясна: интерфейсов как таковых нет, но есть данные, которые можно отправлять и читать, а ещё иногда изменять произвольным образом. Например, в одину область кладём данные для шифровки, из другой достаём результат шифрования. Правильно? Такое приобретение могло бы показаться волшебным джином, если бы не было, в действительности, ненужной (точнее, не выдерживающей конкуренции) женой.
Правильно. И в демо-движке всё прекрасно работает.
Цитата: koderAlex
без разбора идеи я тоже могу привести намеренно испорченный код
интерфйейс у товарища есть - использование отладочный прерываний . только нафига это надо ? и быстродействие такой оси будет ужасным .
интерфйейс у товарища есть - использование отладочный прерываний . только нафига это надо ? и быстродействие такой оси будет ужасным .
Скажите, а что в форуме все имеют права на авторство?
Если все будут открыто демонстрировать свои "тайные" приёмы и коды направо и налево, кто будет автором или сколько будет соавторов???
Интерфейс, Вы правы, есть. Исключительный.
Нафига это надо?
Отпадает надобность в явных системных вызовах. И системный код уже закрыт на 100%. А у приложения имеется память в полные 4Гб без всяких ограничений.
А быстродействие никак не упадёт. Просто все привыкли, например, в Windows к API-функциям SetPixel, BitBlt, GetRValue, gluSphere и т.д. То есть, здесь куча "мусорных" операций CALL. Хотя множество операций можно заменить на единственную. Тысячу SetPixel на одну DrawPixelArray. Десятки BitBlt на одну, а gluSphere и т.п. описать в массив байт-кодом. Тогда обращение к сервисам ОС будет в сотни раз реже, а значит и быстродействие на порядок выше. А VirtualAlloc вообще зачем в качестве функции, если нигде никакое приложение не запрашивает выделение памяти сотни раз в секунду!? Значит, тысячи таких "бессмысленных" API-функций уже выбрасываются вон. А приложение уже может байт-кодом описать схему, типо "arrayX: 320x240x24;*arrayY:*640x480x8;*arrayY*->*arrayX", что примерно может означать как преобразовать массив графики глубиной в 8 бит/пиксел в массив 24 бита/пиксел. Это, конечно, грубый пример. Но, уже напоминает Java-апплет.
Возьмём программирование под DOS. У нас есть прямой доступ к регистрам палитры видяхи, но инструкции IN/OUT чудовищно медленные. Выход? Подготовить массив и махом обновить все регистры с помощью REP*OUTSB.
В моей ОС используется такая же схема. Вместо построения OpenGL-сцены с тысячами вызовов функций графических примитивов нам требуется просто заполнить таблицу байт-кодом и одним лишь исключением LOCK указать системе адрес таблицы. А дальше, пусть хоть OpenGL транслирует байт-код в машинный, но производительность приложения уже оценивается как высокая! Почему?
Если пользователю не давать лишнего повода на вызов тысяч функций API, а строго предложить заполнить байт-код-таблицу, тогда приложения просто не будут тормознутыми от черезчур кривых рук программиста-ламера. Здесь всё уже зависит от реализации ОС. И чем продуманнее построен "исключительный" интерфейс, тем больше повышается производительность всего в целом.
PS: Почему я пишу в основном здесь примеры с графикой: Они очевидны. MenuetOS большей частью изобилует графическим функциями, так-как она, прежде всего, демо-ОС. А так, у меня есть наброски работы с сетью, архиваторами, компиляторами и СУБД. Но, такие примеры, во-первых, тяжело кратко привести. А во-вторых, ещё сложнее будет понять. Так-как не имея под рукой даже эмулятора ОС, тяжело будет понять их простоту на практике, наряду с традиционными средствами API.
Цитата: Vertecs
А быстродействие никак не упадёт. Просто все привыкли, например, в Windows к API-функциям SetPixel, BitBlt, GetRValue, gluSphere и т.д. То есть, здесь куча "мусорных" операций CALL. Хотя множество операций можно заменить на единственную. Тысячу SetPixel на одну DrawPixelArray. Десятки BitBlt на одну, а gluSphere и т.п. описать в массив байт-кодом.
Не слишком ли много памяти понадобится для выполнения всего одной функции? Возьмем, к примеру, SetPixel vs DrawPixelArray. Например, я обрабатываю изображение размерами 1024x768 и хочу его вывести. Один пиксель будет описываться пятью байтами: два по два на координаты и один (и то, в случае 256 цветов) - на цвет. 1024x768x5=3.75 метра. Не слишком ли много?
Цитата:
MenuetOS большей частью изобилует графическим функциями, так-как она, прежде всего, демо-ОС
Скажите это разработчикам КолибриОС (российского клона Menuet) :)
Ну и вдогонку: если команды будут исполняться сразу для массива, то при больших объемах массива не вызовет ли это временную недоступность приложения?
Цитата: dreamer.mas
Не слишком ли много памяти понадобится для выполнения всего одной функции? Возьмем, к примеру, SetPixel vs DrawPixelArray. Например, я обрабатываю изображение размерами 1024x768 и хочу его вывести. Один пиксель будет описываться пятью байтами: два по два на координаты и один (и то, в случае 256 цветов) - на цвет. 1024x768x5=3.75 метра. Не слишком ли много?
В наше время это не довольно огромный массив. К тому же кто мешает разбить его на несколько частей? Приложению доступно до 4Гб собственной памяти и 32Тб подключаемой (в 32-битной версии конечно). Ограничения только в размере винта. Про своп-файл не говорю, его нету в понимании Windowsююю
Цитата: dreamer.mas
Ну и вдогонку: если команды будут исполняться сразу для массива, то при больших объемах массива не вызовет ли это временную недоступность приложения?
Никак нет. Приложение - клиент, всё остальное - серверы. Если Вы по интернету запросили PNG картинку и сервер вдруг на половине "уснул", Ваш компьютер не повиснет же!? ;)
В этой ОС похожая организация. Смотря какой инструкцией и с каким флагом она вызовет "исключительный" вызов.
Цитата: dreamer.mas
Скажите это разработчикам КолибриОС (российского клона Menuet) :)
Благодарю! Попробую! ;)
Цитата: Vertecs
В наше время это не довольно огромный массив. К тому же кто мешает разбить его на несколько частей?
Столько манипуляций ради каких-то единиц, максимум десятков миллисекунд выгоды по сравнению с поточечным выводом... К тому же, раз Вы хотите завязать на этом большое количество часто используемых вызовов, лишние операции по созданию/очистке областей памяти будут сильно фрагментировать память, не так ли?
Цитата:
Никак нет. Приложение - клиент, всё остальное - серверы. Если Вы по интернету запросили PNG картинку и сервер вдруг на половине "уснул", Ваш компьютер не повиснет же!? ;)
То есть, все подобные операции будут асинхронными?
И, наконец, если Вы говорите "в наше время это не довольно огромный массив", то почему бы мне не ответить на это: "в наше время суммарная продолжительность выполнения команд push, call, pop и ret является незначительной"? :)
Цитата: dreamer.mas
Столько манипуляций ради каких-то единиц, максимум десятков миллисекунд выгоды по сравнению с поточечным выводом... К тому же, раз Вы хотите завязать на этом большое количество часто используемых вызовов, лишние операции по созданию/очистке областей памяти будут сильно фрагментировать память, не так ли?
То есть, все подобные операции будут асинхронными?
То есть, все подобные операции будут асинхронными?
Не все. Я уже сказал. Смотря каким образом приложение обратится к ОС через исключение.
Цитата: dreamer.mas
И, наконец, если Вы говорите "в наше время это не довольно огромный массив", то почему бы мне не ответить на это: "в наше время суммарная продолжительность выполнения команд push, call, pop и ret является незначительной"? :)
Ну, и что? Цель ОС основная - полная инкапсуляция приложений. Одно приложений - один комп. Точнее, если приложение "взбесится", то его и закрывать не надо. Оно никак не повредит ни ОС, ни другим приложениям. Так-как системных функций в адресном пространстве приложения нет, то оно находится на уровне BIOS: Вся память, сколько доступно, и "умный" контроллер шины, который назначает нужные устройства на нужные сегменты. А список доступных устройств в этой среде для каждого приложения хранится в своём файле конфигурации. Нужно приложению передать файл с картинкой, посыляем через сервер обмена. Приложение получает запрос и может дать ответ. Т.е. и приложение ведёт себя как мини-сервер. А если оно "взбесилось", попадает в список временного игнорирования, пока пользователь не решит, что делать.
Черезчур частая генерация исключений, причём если их не может понять ни один сервер, говорит ОС что у приложения "бешенство" и ему необходимо понизить приоритет и заблокировать обработку исключений (игнорировать), что сохранит общую производительность без убийства "бешенного". :)
Ну, тут очень много деталей. Всё кратко не опишешь. Это - отдельная тема...
Цитата:
Нужно приложению передать файл с картинкой, посыляем через сервер обмена. Приложение получает запрос и может дать ответ.
Навеяло вполне естественный вопрос: как, имея столь запутанную концепцию, Вы собираетесь обеспечивать безопасность? Вот, например, в Вами приведенном случае где гарантия, что, получив запрос, ответ на него не пошлет другое приложение?
Цитата:
ведёт себя как мини-сервер. А если оно "взбесилось", попадает в список временного игнорирования, пока пользователь не решит, что делать.
Черезчур частая генерация исключений, причём если их не может понять ни один сервер, говорит ОС что у приложения "бешенство" и ему необходимо понизить приоритет и заблокировать обработку исключений (игнорировать), что сохранит общую производительность без убийства "бешенного".
Черезчур частая генерация исключений, причём если их не может понять ни один сервер, говорит ОС что у приложения "бешенство" и ему необходимо понизить приоритет и заблокировать обработку исключений (игнорировать), что сохранит общую производительность без убийства "бешенного".
Больше похоже на субъективную оценку, которая в конечном счете может пойти вразрез со вполне оправданными действиями некоторых приложений.
Из остального ничего не понял, потому не комментирую ;)
Автору темы советую покопаться в ядре MenuetOS или Kolibri. Сам я пока ничего не модифицировал (тяжело заточить его под мою ОС), но там многое открывается ;)
Цитата: dreamer.mas
Навеяло вполне естественный вопрос: как, имея столь запутанную концепцию, Вы собираетесь обеспечивать безопасность? Вот, например, в Вами приведенном случае где гарантия, что, получив запрос, ответ на него не пошлет другое приложение?
Вопрос хороший. Но, концепция ОС какрас подразумевает обмен данными между приложениями, если пользователем назначены каналы связи. Конечно, в Windows это тоже сравнительно легко достигается слежением за буфером обмена или организации серверного обмена с прослушиванием локальных портов. Но, программирование подобных задач может выходить за границы компетенции начинающего программиста. В этой ОС бОльшая часть ответственности лежит на пользователе. Он без опаски может запустить откровенный троян. Но, пока трояну этому не открыты никакие каналы обмена, а главное, файловый сервис, максимум, что может сделать такой троян - "взбеситься" в своём полностью изолированном пространстве и притормаживать систему генерацией исключений.
Тем более что любое приложение само по себе беспомощно. Все его ресурсы описаны отдельным файлом с назначением тех или иным регионов памяти конкретным сервисам. Черновой пример выше демонстрирует "подключение" клавиатуры: /dev/keyboard. Тогда как на деле, если клавиатура не входит в тот файл, код сам и не сможет к ней никак добраться.
Цитата: dreamer.mas
Больше похоже на субъективную оценку, которая в конечном счете может пойти вразрез со вполне оправданными действиями некоторых приложений.
А форум, по-моему, тоже создан для субъективных мнений и оценок... ;)
Цитата: dreamer.mas
Из остального ничего не понял, потому не комментирую ;)
Тогда вот вам ещё пища: ;)
Код:
; Здесь мы рассмотрим простейщий алгоритм и способы его оптимизации, чтобы тем
; самым повысить его производительность.
mov es, [Screen] ; Сегмент экрана
mov ds, [Picture] ; Сегмент изображения
L1: lodsd ; Чтение пиксела
not eax ; Инвертирование
stosd ; Вывод пиксела
loop L1 ; Продолжение...
; Данный пример выводит все пиксели из буфера на экран в инвертированном виде.
; Эта версия генерирует слишком много исключений и получается очень медленной.
; Чтобы повысить производительность, достаточно указать системе весь алгоритм,
; который будет задействован уже внутри системного сервиса:
mov es, [Screen] ; Сегмент экрана
mov ds, [Picture] ; Сегмент изображения
L1: lodsd ; Чтение пиксела
not eax ; Инвертирование
stosd ; Вывод пиксела
lock ; Обращение к системе
loop L1 ; Продолжение...
; Что здесь изменилось? Была лишь добавлена операция, которой определяются все
; инструкции, описывающие алгоритм обработки информации. Прежде чем они начнут
; работать, будет произведён анализ на "чистоту" описания фильтра. Условия:
; 1) Размер кода не должен превышать сотни байтов;
; 2) Запрещены операции вызова процедур или исключений;
; 3) Команды безусловного и условного перехода не могут выходить вне кода;
; 4) Значительная часть должна быть вычислительной;
; 5) Все используемые величины должны указываться только регистрами.
; Теперь разберём механизм "вживления" фильтрующего кода в системные процессы.
; Операции LODS/STOS или другие, заменяются на CALL непосредственно, что также
; увеличивает код на 4 байта с каждой такой операцией. Так-как LOOP может лишь
; охватить до 126 байтов кода, проявляются ограничения на количество операций,
; описывающих работу над строковыми массивами. Это не техническое ограничение,
; а необходимость для сдерживания программиста от излишков. Давайте посмотрим,
; как наш код будет включён в системную функцию:
L1: call GetDword ; Читаем и записываем слова посредством функций
not eax ; Исходя из значений сегментовых регистров, система
call PutDword ; определяет необходимые функции в соответствующих
loop L1 ; библиотеках
ret ; Для чего эта операция - читаем дальше...
; Такой сгенерированный код записывается напрямую во фрейм стека динамически и
; затем выполняется. После завершение работы фрейм восстанавливается, чем этот
; код в последствии просто теряется. Нужно сказать, что у каждой задачи всё же
; имеется кэш подобных фильтров, что избавляет систему от повторной генерации,
; если при этом условия не изменились.
; самым повысить его производительность.
mov es, [Screen] ; Сегмент экрана
mov ds, [Picture] ; Сегмент изображения
L1: lodsd ; Чтение пиксела
not eax ; Инвертирование
stosd ; Вывод пиксела
loop L1 ; Продолжение...
; Данный пример выводит все пиксели из буфера на экран в инвертированном виде.
; Эта версия генерирует слишком много исключений и получается очень медленной.
; Чтобы повысить производительность, достаточно указать системе весь алгоритм,
; который будет задействован уже внутри системного сервиса:
mov es, [Screen] ; Сегмент экрана
mov ds, [Picture] ; Сегмент изображения
L1: lodsd ; Чтение пиксела
not eax ; Инвертирование
stosd ; Вывод пиксела
lock ; Обращение к системе
loop L1 ; Продолжение...
; Что здесь изменилось? Была лишь добавлена операция, которой определяются все
; инструкции, описывающие алгоритм обработки информации. Прежде чем они начнут
; работать, будет произведён анализ на "чистоту" описания фильтра. Условия:
; 1) Размер кода не должен превышать сотни байтов;
; 2) Запрещены операции вызова процедур или исключений;
; 3) Команды безусловного и условного перехода не могут выходить вне кода;
; 4) Значительная часть должна быть вычислительной;
; 5) Все используемые величины должны указываться только регистрами.
; Теперь разберём механизм "вживления" фильтрующего кода в системные процессы.
; Операции LODS/STOS или другие, заменяются на CALL непосредственно, что также
; увеличивает код на 4 байта с каждой такой операцией. Так-как LOOP может лишь
; охватить до 126 байтов кода, проявляются ограничения на количество операций,
; описывающих работу над строковыми массивами. Это не техническое ограничение,
; а необходимость для сдерживания программиста от излишков. Давайте посмотрим,
; как наш код будет включён в системную функцию:
L1: call GetDword ; Читаем и записываем слова посредством функций
not eax ; Исходя из значений сегментовых регистров, система
call PutDword ; определяет необходимые функции в соответствующих
loop L1 ; библиотеках
ret ; Для чего эта операция - читаем дальше...
; Такой сгенерированный код записывается напрямую во фрейм стека динамически и
; затем выполняется. После завершение работы фрейм восстанавливается, чем этот
; код в последствии просто теряется. Нужно сказать, что у каждой задачи всё же
; имеется кэш подобных фильтров, что избавляет систему от повторной генерации,
; если при этом условия не изменились.
2 hardcase, ты бы лучше что нибудь по теме написал.
2 Washington
2 Washington
Цитата:
дык поражает когда человек, впервые столкнувшись с программированием...
ты не прав. точнее
Цитата:
впервые столкнувшись с программированием на таком уровне
2 Vertecs
Поверьте, с моими знаниями я вам вряд ли буду полезен... тем более командная работа людей у которых нет возможности для живого диалога по теме, ИМХО практически невозможна Ж))
но я думаю Вы мне сможете чем нибудь помочь :) киньте асю вличку...
2 Phodopus
Цитата:
Если он хочет декодировать mp3/jpeg/aac/ogg/mpeg4/h263 я думаю он этого еще очень-очень долго не сделает
возможно... не всё же сразуЖ) (если ты в чём-то не разобрался, это ещё не значит что другие последуют за тобой :) )
Цитата:
Редкостный бред спрашивать на форуме о том как написать операционку. Равносильно что спросить как написать программу.
Я что спросил КАК ЕЁ ПИСАТЬ? (читай первый пост) мне нужны ответы на пару теоритических вопросов, так же мне нужно знать где, что, по какому адресу располагается, куда, что можно писать, структура жесткого диса и т д... почти все эти вопросы освещены на по ссылочке данной dreamer.mas, за что ему огромное спасибо, читаю.
зная что и где + знание asm+ мозг, можно написать ОС
2logree. Из вашего вопроса трудно сделать вывод, о том, что вы начинающий гений.
2Vertecs. А вы не задумывались, насколько ваша ОС может быть переносима на архитектуры, отличные от x86? А как ваша ОС будет противостоять вирусам, хотябы элементарному переполнению буфера? А насколько можно будет верифицировать поведение программы под такой ОС? Попробуйте ответить на эти вопросы.
2Vertecs. А вы не задумывались, насколько ваша ОС может быть переносима на архитектуры, отличные от x86? А как ваша ОС будет противостоять вирусам, хотябы элементарному переполнению буфера? А насколько можно будет верифицировать поведение программы под такой ОС? Попробуйте ответить на эти вопросы.
Цитата: logree
Поверьте, с моими знаниями я вам вряд ли буду полезен... тем более командная работа людей у которых нет возможности для живого диалога по теме, ИМХО практически невозможна Ж))
но я думаю Вы мне сможете чем нибудь помочь киньте асю вличку...
но я думаю Вы мне сможете чем нибудь помочь киньте асю вличку...
Как я понял, затея с ОС чисто из-за мультимедии? Если так, то чем не подходит этот плеер?;)
http://www.multimediaware.com/qv/
Пользуюсь им в среде ДОС когда "приспичит" и всё ОК :)
ICQ давать не стану, так-как сам с начала года никак туда подключиться не могу. Дурацкая ася пятая обнаружила обновление и требует его скачать. Про QiP не заикаться! ;)
Цитата: hardcase
А вы не задумывались, насколько ваша ОС может быть переносима на архитектуры, отличные от x86?
Задумывался. Что интересно, приложения её 100% легко могут работать на любой другой ОС в специально созданой среде (по типу VDM) без какой-либо переделки. А вот на счёт других архитектур процессоров получается ситуация, как и с демо-ОС MenuetOS и KolibriOS. Они практической и инструментальной ценности не представляют. Только как обучающие. В моём же случае ОС получается более серъёзная, но не переносимая...
Цитата: hardcase
А как ваша ОС будет противостоять вирусам, хотябы элементарному переполнению буфера? А насколько можно будет верифицировать поведение программы под такой ОС? Попробуйте ответить на эти вопросы.
Когда я занялся концепцией своей ОС, то именно защита от вредительского кода подсказала просто исключить все API из пространства приложения. Получаем в итоге такую ситуацию:
На столе два компьютера. Один - поражён вирусом, второй - нет. Само собою, первый никак физически не сможет передать свою заразу второму. А вот мы, пользователи, можем создать благоприятное условие: Берём мануал и соединяем эти два компьютера нуль-модемным кабелем. Теперь вирус в первом компьютере может через интерфейс второй и заразить его...
О чём это говорит? Как я уже говорил, само приложение не сможет даже к клавиатуре доступ получить, если та не прописана в конфигурации этого приложения. Т.е. приложение может получить всё строго только по "рецепту". Нет рецепта на доступ к файлам, не будет и доступа. Но, через системный менеджер можно назначить сегмент приложения как зеркало на файл, хотя приложение может принять его за консоль. Вообще-то, это широкая тема... Переполнение буффера - больное место "традиционных" ОС. Если даже оно и случится, приложение будет подобно внешнему модему, у которого стек сбился и он повис, а компьютер от этого ничуть не страдает.
Может, просто, видимо, Вы не хотите или не можете хоть чуточку вдуматься в концепцию и даже смутно представить такую ОС?... ;)
Цитата: Vertecs
Когда я занялся концепцией своей ОС, то именно защита от вредительского кода подсказала просто исключить все API из пространства приложения.
Сомнительно... или просто нужно точнее определить API. Приложение так и или иначе будет подгружать различного рода библиотеки.
Цитата: Vertecs
Т.е. приложение может получить всё строго только по "рецепту". Нет рецепта на доступ к файлам, не будет и доступа. Но, через системный менеджер можно назначить сегмент приложения как зеркало на файл, хотя приложение может принять его за консоль.
Это называетс манифест. В Singularity именно так и происходит.
Цитата: Vertecs
Переполнение буффера - больное место "традиционных" ОС. Если даже оно и случится, приложение будет подобно внешнему модему, у которого стек сбился и он повис, а компьютер от этого ничуть не страдает.
Компьютер-то ладно ничего с ним не случится. Проблема в другом. Получивший шэлл-код системный сервис имел доступ к разым интересным данным в системе, соответственно вирусяка теперь тоже имеет к ним доступ - проникновение-то мы и упустили. Это главное.
Цитата: Vertecs
Может, просто, видимо, Вы не хотите или не можете хоть чуточку вдуматься в концепцию и даже смутно представить такую ОС?... ;)
Я не знаю ассемблер и архитектуру x86 настолько хорошо, чтобы оценить по достоинству вашу схему. Я понял лишь смутную мысль. Пытаюсь вот сравнить вашу схему с Singularity: единая система типов, верификация кода, программная изоляция процессов и много всего интересного-вкусного и, самое главное, уже вополощенного.
Цитата: hardcase
Сомнительно... или просто нужно точнее определить API.
Ответ в конце :)
Цитата: hardcase
Приложение так и или иначе будет подгружать различного рода библиотеки.
Не будет. Ответ в конце :)
Цитата: hardcase
Это называетс манифест. В Singularity именно так и происходит.
:)
Цитата: hardcase
Компьютер-то ладно ничего с ним не случится. Проблема в другом. Получивший шэлл-код системный сервис имел доступ к разым интересным данным в системе, соответственно вирусяка теперь тоже имеет к ним доступ - проникновение-то мы и упустили. Это главное.
Я не знаю ассемблер и архитектуру x86 настолько хорошо, чтобы оценить по достоинству вашу схему. Я понял лишь смутную мысль. Пытаюсь вот сравнить вашу схему с Singularity: единая система типов, верификация кода, программная изоляция процессов и много всего интересного-вкусного и, самое главное, уже вополощенного.
Я не знаю ассемблер и архитектуру x86 настолько хорошо, чтобы оценить по достоинству вашу схему. Я понял лишь смутную мысль. Пытаюсь вот сравнить вашу схему с Singularity: единая система типов, верификация кода, программная изоляция процессов и много всего интересного-вкусного и, самое главное, уже вополощенного.
Отвечаю:
Незнание ассемблера сильно мешает в Вашем случае. Так-как на высоком уровне без функций или API сложно существовать.
1) API так и так не нужно. Всё равно, что запущенная в эмуляторе VMWare/Bochs программа будет явно обращаться к API этих эмуляторов;
2) Библиотеки не нужны явно. Но, а так, ОС сама определит, какие нужны. Библиотеки же самого приложения запускаются как прилагаемое к нему приложение и работает как сервер;
3) Вирус просто не способен сбить стек сервиса. Это всё равно, что грубым матом на форуме повесить целый сервер или вызвать перезагрузку. Или же комбинацией инструкций вызвать сильнейший сбой Bochs/VMWare так, что часть кода выполнится на уровне ядра! ;)
Singularity хорошо. Но, там всё-таки не используется максимум возможностей процессора. В концепции моей ОС же лежит правило использования максимума всей начинки процессора, чтобы один сложный механизм заменял сотню простейщих, при этом, значительно повышая производительность. Чтобы понять эту фразу, очень советую изучить всего две x86-инструкции:
одна PUSHAD и одна POPAD против семи PUSH R32 и семи POP R32...
Тем самым, ОС использует один, но сложный механизм, против сотни, но простых. Тем самым, когда скорость одного сложного находится на уровне 98 простых, оптимальнее выполнить один сложный, чем 100 простых...
Надеюсь, что ясно изложил данную суть.
P.S.: Правлю, так-как только сейчас нашёл короткий путь к описанию общей модели моей ОС:
Традиционно, Unix, CP/M-80, DOS, Windows, Linux и т.д., короче, все системы, включая MenuetOS и QNX, предоставляют собственные системные функции, чтобы приложение, манипулируя ими, достигла нужной цели.
В основе моей же ОС лежит обратная схема: Приложения описывает системе схему своих манипуляций с данными, а система компонует временный сервер и вставляет в него все API и схемы манипуляций, а затем запускает его практически на уровне ядра. Если скомпонованный сервер "упал", приложение не страдает и продолжает работать, получив лишь оповещение об ошибке. Всё равно, что страница HTML "Сервер перегружен, повторите запрос позднее". Напоминает SSI, не так ли?
Всё.
ваша идея (по крайней мере в таком виде) нежизнеспособна .
1) вам приходится (по вашим же словам) эмулировать "умный котроллер шины" .
2) при обращении к оси через исключение кроме переключения задачи (которое производится во всех ОС) , нужно обязательно анализировать источник исключения (иначе ваша ось может перепутать апи-вызов с действительным исключением) , а это будет тормозить систему .
3) принуждать пользователя выводить графику массивом ради одного пикселя - маразм .
4) если приложению разрешено создавать и/или открывать файлы с произвольными именами , то никакая изоляция процессов в памяти от заражения не поможет .
а если вы запретите приложению это делать , то ваша ось не будет востребована .
5) ни одно приложение не может иметь произвольный доступ (в 32 версии) ко всем 4 гигам по очевидным соображениям .
1) вам приходится (по вашим же словам) эмулировать "умный котроллер шины" .
2) при обращении к оси через исключение кроме переключения задачи (которое производится во всех ОС) , нужно обязательно анализировать источник исключения (иначе ваша ось может перепутать апи-вызов с действительным исключением) , а это будет тормозить систему .
3) принуждать пользователя выводить графику массивом ради одного пикселя - маразм .
4) если приложению разрешено создавать и/или открывать файлы с произвольными именами , то никакая изоляция процессов в памяти от заражения не поможет .
а если вы запретите приложению это делать , то ваша ось не будет востребована .
5) ни одно приложение не может иметь произвольный доступ (в 32 версии) ко всем 4 гигам по очевидным соображениям .
[QUOTE=Vertecs]Singularity хорошо. Но, там всё-таки не используется максимум возможностей процессора.[/QUOTE]Управляемый код, положенный в основу Singularity, как раз и даёт возможность использовать все возможности процессора (и не только процессора). Фактически, управляемый код максимально легко и эффективно устраняет проблему, решаемую в Linux распространением программ в виде исходного кода: прога компилируется под конкретную архитектуру и конкретный процессор. Более того, процессом итоговой компиляции приложения можно управлять в невероятно широких пределах: например, при параллельных вычислениях, автоматически компилировать прогу так, чтобы количество порождаемых в ней потоков было в точности равно количеству процессоров. Программа, использующая не доверяемый ей функционал ОС, просто не скомпилируется. +100% Обектно-ориентированный программный интерфейс для приложений. И всё это поддерживается на уровне операционки.
Цитата:
Как я понял, затея с ОС чисто из-за мультимедии?
В принципе да, но моя задача ещё в том, чтобы научиться писать на низком уровне и самому разобраться как что работает, построение ОС - задача промежуточная, мне нужно знать систему как свои пять пальцев, просто дальше задача будет ещё более сложной.
я уж даже не говорю про то что дос - 16.
Цитата: koderAlex
ваша идея (по крайней мере в таком виде) нежизнеспособна .
1) вам приходится (по вашим же словам) эмулировать "умный котроллер шины" .
2) при обращении к оси через исключение кроме переключения задачи (которое производится во всех ОС) , нужно обязательно анализировать источник исключения (иначе ваша ось может перепутать апи-вызов с действительным исключением) , а это будет тормозить систему .
3) принуждать пользователя выводить графику массивом ради одного пикселя - маразм .
4) если приложению разрешено создавать и/или открывать файлы с произвольными именами , то никакая изоляция процессов в памяти от заражения не поможет .
а если вы запретите приложению это делать , то ваша ось не будет востребована .
5) ни одно приложение не может иметь произвольный доступ (в 32 версии) ко всем 4 гигам по очевидным соображениям .
1) вам приходится (по вашим же словам) эмулировать "умный котроллер шины" .
2) при обращении к оси через исключение кроме переключения задачи (которое производится во всех ОС) , нужно обязательно анализировать источник исключения (иначе ваша ось может перепутать апи-вызов с действительным исключением) , а это будет тормозить систему .
3) принуждать пользователя выводить графику массивом ради одного пикселя - маразм .
4) если приложению разрешено создавать и/или открывать файлы с произвольными именами , то никакая изоляция процессов в памяти от заражения не поможет .
а если вы запретите приложению это делать , то ваша ось не будет востребована .
5) ни одно приложение не может иметь произвольный доступ (в 32 версии) ко всем 4 гигам по очевидным соображениям .
Я не понимаю. Неужели не попытаться выйти за рамки мышления традиционных ОС, чтобы понять подобную ОС? ;) Потому что ответы очевидны:
1) "умный контроллер шины" - это подобие монитора и муршрутизатора. В NT среде DOS приложение находится под надзором VDM, которая может эмулировать SB16 и т.п. так, что приложение этого не заметит. На деле же, эмулировать "умный контроллер шины" - просто неверно сказано. Эмуляция - симуляция существующего девайса. А здесь же, "умным контроллером" является монитор, ничуть не сложнее кода, заботящимся о подкачке страниц;
2) подкачка несуществующих страниц и их кэширование на диске - прозрачный процесс для приложения. Здесь источник исключения определяется автоматически. И снова я говорю, явных функций API нету. По-этому всё меняется;
3) а ОС и не принуждает. Я же представил выше пример, где большие объёмы пикселей обрабатываются на стороне ОС по описываемому приложением алгоритму;
4) опять прошу ПОПЫТАТЬСЯ выйти за рамки мышления рядового программирования. В среде DOS программа как может работать с HD без DOS-API? Через порты, на уровне секторов и т.д., т.е. "копаться в общей куче". В этой ОС же имена файлов или каталогов не существует для приложения в обычном понимании. Если мы плееру хотим передать три MP3-файла, то никаких сведений о пути и их именах он не получит. Только в пространстве его памяти появятся три страницы памяти - зеркал на те файлы. Итог: Максимальная абстракция;
5) может, если подкачивать несуществующие страницы. Так, память открыта приложению не физическая, а виртуальная! А это значит, что можно сделать так, чтобы 32-разрядное слово умещалось в одну ячейку без разбиения на 4. Т.е. виртуальный ассоциативным массив, где одна адресуемая ячейка - не байт, а элемент массива. Пусть даже строковой. Производительность упадёт, это очевидно. Но, я пример привёл для примера, а не для описания основ ОС. Просто приложению выделяется 4Гб памяти для произвольного доступа. Если приложение вздумает обращатся в несуществующие ячейки, эффект будет как в среде DOS: Нулевой. Запись в них ничего не меняет, а чтение возврашает произвольный код. Тормозиться будет система? Нет. Если несуществующую страницу описать сотней маленьких страниц как зеркала на одну существующую (4кб скажем). Получится, что приложение, обращаясь ко всем 4Гб ячеек будет крутиться в 4кб, не мешая самой ОС генерацией исключения. Тем самым, приложение может беситься в своём клочке памяти, а на ОС это никак не отразится.
Цитата: Der Meister
Управляемый код, положенный в основу Singularity, как раз и даёт возможность использовать все возможности процессора (и не только процессора). Фактически, управляемый код максимально легко и эффективно устраняет проблему, решаемую в Linux распространением программ в виде исходного кода: прога компилируется под конкретную архитектуру и конкретный процессор. Более того, процессом итоговой компиляции приложения можно управлять в невероятно широких пределах: например, при параллельных вычислениях, автоматически компилировать прогу так, чтобы количество порождаемых в ней потоков было в точности равно количеству процессоров. Программа, использующая не доверяемый ей функционал ОС, просто не скомпилируется. +100% Обектно-ориентированный программный интерфейс для приложений. И всё это поддерживается на уровне операционки.
Отдельная тема. ОС, насколько я знаю, от MS. Похоже, это их новая увлекательная идея. В своё время Windows'95 тоже захвативало дух у пользователей и ламер-кодеров.
Цитата: logree
Возникла необходимость написать свою Операционку ...
Наверное, была допущена опечатка.
Как это возникла необходимость? Задали в качестве домашнего задания?
Корректнее было бы сказать, мол заинтересовался механизмами ОС или имею идею написать мультимедийный плеер, начиная с Boot-сектора.
Цитата: logree
В принципе да, но моя задача ещё в том, чтобы научиться писать на низком уровне и самому разобраться как что работает, построение ОС - задача промежуточная, мне нужно знать систему как свои пять пальцев, просто дальше задача будет ещё более сложной.
я уж даже не говорю про то что дос - 16.
я уж даже не говорю про то что дос - 16.
В таком случае, разбирайтесь в KolibriOS, удалите лишние приложения и напишите одно большое: медиа-плеер. Грузиться всё будет за секунды и открывать файлы с CD-ROM... Получится мульти-медийный дистрибутив KolibriOS? Не привлекательно?
Кодишь на ассемблере в 32-битной среде.
Говорю, скачать надо тот плеер (линк выше я дал) и всё.
Цитата: logree
В принципе да, но моя задача ещё в том, чтобы научиться писать на низком уровне и самому разобраться как что работает, построение ОС - задача промежуточная, мне нужно знать систему как свои пять пальцев, просто дальше задача будет ещё более сложной.
я уж даже не говорю про то что дос - 16.
я уж даже не говорю про то что дос - 16.
Брось эту затею увязнишь. Как я в свое время. =)
Если будут конкретные вопросы спрашивай отвечу.
Сингулярити хорошая задумка. А вообще это эксперементальная ОС.
На самом деле все сводиться к разно маштабным уровням.
1. Офисные приложения. Им нужно читать из файлов выводить данные на экран работать с сетью(пересылка данных).
2. Служебные приложения которые работают на промяжуточном уровне. Они задействуют особенности системы, они знают о них.
3. Драйвера они реализуют низкоуровнивые механизмы с которыми общаются приложения 2.
От приложений 2 нельзя отказаться. Даже более того они входят в приложения 1.
Сингулярити поидее должна это разруливать. Только вот для этого нужны немалые затраты. Соизмеримые с мировой индустрией IT. Отсюда выход опенскоре или создание технологии NET+COM. Только применять ее надо к компилятору(интерпритатору).
Так что тут перспективы за облочные.
128 байт мало для вычислительного кода.
128/4=32 команды у меня FFT не влазит. Темболее оперирует он не с регистрами ему память нужна. Правда это уже тема отдельного разговора.
Цитата: Vertecs
В основе моей же ОС лежит обратная схема: Приложения описывает системе схему своих манипуляций с данными, а система компонует временный сервер и вставляет в него все API и схемы манипуляций, а затем запускает его практически на уровне ядра. Если скомпонованный сервер "упал", приложение не страдает и продолжает работать, получив лишь оповещение об ошибке.
Грубо говоря, так и происходит с SIPами в Сингулярке. У исполняемой сборки есть манифест описывающий аспекты поведения прложения. У некоторых типов в сборке есть специальные атрибуты, также декларирующие поведение. Компилятор все это вместе собирает в единое целое (а у него предостаточно информации для разного рода оптимизаций) и собирает исполнимый код. Добавьте сюда автоматическое распределение памяти, статическую верификацию кода и абсолютную типизацию - мы получим программную систему со вполне предсказуемым поведением. Это ли не счастье?
Цитата: Vertecs
Я не понимаю. Неужели не попытаться выйти за рамки мышления традиционных ОС, чтобы понять подобную ОС? ;) Потому что ответы очевидны:
зачем выходить за рамки ? у вас обычная ось , только апи сделано (извените , но я скажу по русски) "через задницу" .
Цитата: Vertecs
1) "умный контроллер шины" - это подобие монитора и муршрутизатора. В NT среде DOS приложение находится под надзором VDM, которая может эмулировать SB16 и т.п. так, что приложение этого не заметит. На деле же, эмулировать "умный контроллер шины" - просто неверно сказано. Эмуляция - симуляция существующего девайса. А здесь же, "умным контроллером" является монитор, ничуть не сложнее кода, заботящимся о подкачке страниц;
"умный контроллер шины" - это ваши слова , я тут не причём . и зачем симулировать существующий девайс ? эмуляция SB16 в VDM для DOS приложения производится вполне определённым аппаратным механизмом (картой портов IO) , а у вас чем ?
Цитата: Vertecs
2) подкачка несуществующих страниц и их кэширование на диске - прозрачный процесс для приложения. Здесь источник исключения определяется автоматически. И снова я говорю, явных функций API нету. По-этому всё меняется;
поправка : логически прозрачный . ось не даёт выполнятся приложению до тех пор пока затребованая страница не окажется в физической памяти . по русски это называется "тормоза" .
Цитата: Vertecs
3) а ОС и не принуждает. Я же представил выше пример, где большие объёмы пикселей обрабатываются на стороне ОС по описываемому приложением алгоритму;
вы противоречите сами себе . или вы принуждаете ползователя использовать только массивы , или разрешаете попиксельно , но в таком случае пользователь имеет право весь вывод массива делать попиксельно .
Цитата: Vertecs
4) опять прошу ПОПЫТАТЬСЯ выйти за рамки мышления рядового программирования. В среде DOS программа как может работать с HD без DOS-API? Через порты, на уровне секторов и т.д., т.е. "копаться в общей куче". В этой ОС же имена файлов или каталогов не существует для приложения в обычном понимании. Если мы плееру хотим передать три MP3-файла, то никаких сведений о пути и их именах он не получит. Только в пространстве его памяти появятся три страницы памяти - зеркал на те файлы. Итог: Максимальная абстракция;
приведитете описательный пример кто что делает с точностью до структур . ну например конвертор *.wav -> *.mp3 . надо приложению сконвертировать произволное кол-во файлов из неизвестного пока места и с неизвестными пока именами в мптришки . простая задачка .
Цитата: Vertecs
5) может, если подкачивать несуществующие страницы. Так, память открыта приложению не физическая, а виртуальная! А это значит, что можно сделать так, чтобы 32-разрядное слово умещалось в одну ячейку без разбиения на 4. Т.е. виртуальный ассоциативным массив, где одна адресуемая ячейка - не байт, а элемент массива.
а элемент массива разве не может быть байтовым? )выбы определились , что именно вы делаете : или разрешаете использовать приложению всё адресноо пространство или запрещаете .
Цитата: Vertecs
Пусть даже строковой. Производительность упадёт, это очевидно. Но, я пример привёл для примера, а не для описания основ ОС. Просто приложению выделяется 4Гб памяти для произвольного доступа. Если приложение вздумает обращатся в несуществующие ячейки, эффект будет как в среде DOS: Нулевой. Запись в них ничего не меняет, а чтение возврашает произвольный код. Тормозиться будет система? Нет. Если несуществующую страницу описать сотней маленьких страниц как зеркала на одну существующую (4кб скажем).
вы , похоже , не понимаете работы защищенного режима х86 процессоров .
Цитата: Vertecs
Получится, что приложение, обращаясь ко всем 4Гб ячеек будет крутиться в 4кб, не мешая самой ОС генерацией исключения. Тем самым, приложение может беситься в своём клочке памяти, а на ОС это никак не отразится.
это отразится ,по крайней мере ,на производительности . )
Цитата: koderAlex
зачем выходить за рамки ? у вас обычная ось , только апи сделано (извените , но я скажу по русски) "через задницу" .
Хм... Ну, аналог DOS "высокого" уровня. Все порты и ячейки - зеркала не на примитивные контроллеры, DMA, LPT, COM, таймеры и клавиатуры, а модели OpenAL, OpenGL, пусть даже DirectX или библиотеки Bass/FMod. Короче, чтобы проиграть миди-файл, достаточно написать программку меньше, чем весит вот этот :D смайлик.
Цитата: koderAlex
"умный контроллер шины" - это ваши слова , я тут не причём . и зачем симулировать существующий девайс ? эмуляция SB16 в VDM для DOS приложения производится вполне определённым аппаратным механизмом (картой портов IO) , а у вас чем ?
Как это чем? А если у Вас стоит совсем не SB16, а уникальная(современная)? Тогда эмулировать порты SB16 в VDM будет куча слоёв HEL и HAL. Не так ли? А тогда все огибающие и DMA будут чисто программно эмулироваться.
Причём, зачем симулировать существующий девайс - странный вопрос, если мы хотим предоставить приложению средства на высоком уровне! Как, например, одна функция PlaySound винды. Просто и коротко. Здесь эмулировать железо вообще не требуется, т.к. приложению порты не нужны.
Цитата: koderAlex
поправка : логически прозрачный . ось не даёт выполнятся приложению до тех пор пока затребованая страница не окажется в физической памяти . по русски это называется "тормоза" .вы противоречите сами себе . или вы принуждаете ползователя использовать только массивы , или разрешаете попиксельно , но в таком случае пользователь имеет право весь вывод массива делать попиксельно .
Говорю, массивы не принудительные. У Win-GDI есть функция LineDDA. Конечно, пользоваться ею - маразм. Но, какрас этот принцип я задействовал в принципах ОС. Сложно, конечно, привести очень ясный пример. Выше я пытался представить ОДИН из таких приёмов.
А тормоза? Если перед обращением к памяти предупредить ОС о том, что есть намеренья обратиться к какой-то области, то тормозов не будет. И ниже я приведу пример.
Цитата: koderAlex
приведитете описательный пример кто что делает с точностью до структур . ну например конвертор *.wav -> *.mp3 . надо приложению сконвертировать произволное кол-во файлов из неизвестного пока места и с неизвестными пока именами в мптришки . простая задачка .
Достаточно сложный случай. Но у меня был пример проигрывания файла, когда ещё я только начал заниматься концепцией.
Цитата: koderAlex
а элемент массива разве не может быть байтовым? )выбы определились , что именно вы делаете : или разрешаете использовать приложению всё адресноо пространство или запрещаете .
вы , похоже , не понимаете работы защищенного режима х86 процессоров . это отразится ,по крайней мере ,на производительности . )
вы , похоже , не понимаете работы защищенного режима х86 процессоров . это отразится ,по крайней мере ,на производительности . )
Понимаю, не понимаю... Если обратиться к сегменту, объявленным как байтовый массив, инструкцией DWORD-доступа, то прочтён будет только байт! Но, ширина DWORD сработает опционально для некоторых механизмов ОС. Как имено - это уже детали и вдаваться в них не буду: Это выходит за рамки темы...
Здесь я просто приведу примеры работы с аудио:
Код:
mov ds, wavHandle ; Сегмент wav-потока
mov es, mp3Handle ; Сегмент mp3-потока. Конвертируем wav->mp3
;mov ds, wavHandle ; Сегмент mp3-потока
;mov es, mp3Handle ; Сегмент wav-потока. Конвертируем mp3->wav
mov ecx, -1 ; Размер - автоматический
rep movsd ; Перемещение данных. Так-как оба сегмента объявлены
; разным сервисам и мы не имеем к ним прямой доступ,
; это вызовет исключение. ОС, тем самым, сама пошлёт
; запрос на переработку данных.
jo doWaiting ; Если после строковой функции указать этот контроль
; на переполнение, задача не будет приостановлена. А
... ; о том, закончилось ли конвертирование, можно узнать
; инструкциями VERR процессора.
;;;;;;;;;;;;;;;;;;;;;
;mov ds, wavHandle ; Сегмент mp3-потока
mov ds, mp3Handle ; Сегмент mp3-потока
mov es, sndDevice ; Сегмент звукового устройства
L1: ; Для чего эта метка - смотрим ниже
mov ecx, -1 ; Нужно проиграть всё. Иначе, можно управлять позицией
rep movsd ; Перемещение данных. А вернее, перенаправление потока
; из памяти напрямую в сервис проигрывания Media.
jno doWaiting ; Указываем, что мы хотим знать о проигрываемой позиции
doWaiting: ; через регистр ECX без приостановки задачи.
jecxz L2 ; Если счётчик обнулился, поток исчерпан.
... ; Иначе, тут выводим текущую позицию на экран
jmp L1 ; и продолжаем это до конца потока.
;;;;;;;;;;;;;;;;;;;;;
; Здесь мы подготовим всё, что необходимо для дальнейщей работы:
OpenSoundDevice: ; Открытие звукового устройства
lea esi,[sndName] ; Указываем имя устройства
mov es, sndDevice ; Сегмент, который станет звуковым
xor edi,edi ; Сегмент объявляется в самом начале
lock mov [edi],esi ; Объявляем!
jo isFault ; Если переполнение, устройство не было назначено, а
; EAX содержит код ошибки
... ; Остальные сегменты назначаются подобным образом
;;;;;;;;;;;;;;;;;;;;;
sndName db '/dev/soundsrv',0 ; Имя сервиса звука
mp3Head db 'RIFF',62,0,0,0,'WAVEfmt ' ; Стандартный RIFF-заголовок для
db 30,0,0,0, 55,0,2,0 ; RIFF-структуры mp3-потока
dd 44100,24000 ; Значения частоты и объёма потока
... ; Описываем по стандарту
wavHead ... ; Всё то же описание RIFF-структуры
mov es, mp3Handle ; Сегмент mp3-потока. Конвертируем wav->mp3
;mov ds, wavHandle ; Сегмент mp3-потока
;mov es, mp3Handle ; Сегмент wav-потока. Конвертируем mp3->wav
mov ecx, -1 ; Размер - автоматический
rep movsd ; Перемещение данных. Так-как оба сегмента объявлены
; разным сервисам и мы не имеем к ним прямой доступ,
; это вызовет исключение. ОС, тем самым, сама пошлёт
; запрос на переработку данных.
jo doWaiting ; Если после строковой функции указать этот контроль
; на переполнение, задача не будет приостановлена. А
... ; о том, закончилось ли конвертирование, можно узнать
; инструкциями VERR процессора.
;;;;;;;;;;;;;;;;;;;;;
;mov ds, wavHandle ; Сегмент mp3-потока
mov ds, mp3Handle ; Сегмент mp3-потока
mov es, sndDevice ; Сегмент звукового устройства
L1: ; Для чего эта метка - смотрим ниже
mov ecx, -1 ; Нужно проиграть всё. Иначе, можно управлять позицией
rep movsd ; Перемещение данных. А вернее, перенаправление потока
; из памяти напрямую в сервис проигрывания Media.
jno doWaiting ; Указываем, что мы хотим знать о проигрываемой позиции
doWaiting: ; через регистр ECX без приостановки задачи.
jecxz L2 ; Если счётчик обнулился, поток исчерпан.
... ; Иначе, тут выводим текущую позицию на экран
jmp L1 ; и продолжаем это до конца потока.
;;;;;;;;;;;;;;;;;;;;;
; Здесь мы подготовим всё, что необходимо для дальнейщей работы:
OpenSoundDevice: ; Открытие звукового устройства
lea esi,[sndName] ; Указываем имя устройства
mov es, sndDevice ; Сегмент, который станет звуковым
xor edi,edi ; Сегмент объявляется в самом начале
lock mov [edi],esi ; Объявляем!
jo isFault ; Если переполнение, устройство не было назначено, а
; EAX содержит код ошибки
... ; Остальные сегменты назначаются подобным образом
;;;;;;;;;;;;;;;;;;;;;
sndName db '/dev/soundsrv',0 ; Имя сервиса звука
mp3Head db 'RIFF',62,0,0,0,'WAVEfmt ' ; Стандартный RIFF-заголовок для
db 30,0,0,0, 55,0,2,0 ; RIFF-структуры mp3-потока
dd 44100,24000 ; Значения частоты и объёма потока
... ; Описываем по стандарту
wavHead ... ; Всё то же описание RIFF-структуры
Цитата: Vertecs
Говорю, массивы не принудительные.
Цитата: Vertecs
В моей ОС используется такая же схема. Вместо построения OpenGL-сцены с тысячами вызовов функций графических примитивов нам требуется просто заполнить таблицу байт-кодом и одним лишь исключением LOCK указать системе адрес таблицы. А дальше, пусть хоть OpenGL транслирует байт-код в машинный, но производительность приложения уже оценивается как высокая! Почему?
Если пользователю не давать лишнего повода на вызов тысяч функций API, а строго предложить заполнить байт-код-таблицу, тогда приложения просто не будут тормознутыми от черезчур кривых рук программиста-ламера.
Если пользователю не давать лишнего повода на вызов тысяч функций API, а строго предложить заполнить байт-код-таблицу, тогда приложения просто не будут тормознутыми от черезчур кривых рук программиста-ламера.
ну я прям не знаю где и когда верить тому , что вы говорите . вы , если что , рукой махните когда верить . )
ваш код ужасен . как по конструкции , так и по производительности .
создание оси начинается не с загрузчика и не с примеров кода , а с таких нудных вещей как формальное описание АПИ , формата исполняемого файла и распределения памяти процессов . :)
Цитата: Vertecs
Хм... Ну, аналог DOS "высокого" уровня. Все порты и ячейки - зеркала не на примитивные контроллеры, DMA, LPT, COM, таймеры и клавиатуры, а модели OpenAL, OpenGL, пусть даже DirectX или библиотеки Bass/FMod. Короче, чтобы проиграть миди-файл, достаточно написать программку меньше, чем весит вот этот :D смайлик.
обещать маленький размер программки - преждевременно , т.к. вы ось ещё не сделали . а всё вышеперечисленное прекрасно делает почти любая современная ось , используя при этом нормальный апи механизм .
Цитата: Vertecs
Как это чем? А если у Вас стоит совсем не SB16, а уникальная(современная)? Тогда эмулировать порты SB16 в VDM будет куча слоёв HEL и HAL. Не так ли? А тогда все огибающие и DMA будут чисто программно эмулироваться.
Причём, зачем симулировать существующий девайс - странный вопрос, если мы хотим предоставить приложению средства на высоком уровне! Как, например, одна функция PlaySound винды. Просто и коротко. Здесь эмулировать железо вообще не требуется, т.к. приложению порты не нужны.
Причём, зачем симулировать существующий девайс - странный вопрос, если мы хотим предоставить приложению средства на высоком уровне! Как, например, одна функция PlaySound винды. Просто и коротко. Здесь эмулировать железо вообще не требуется, т.к. приложению порты не нужны.
нет , не так . во первых достаточно и одного слоя эмуляции . во вторых лучше иметь 10 слоёв эмуляции с быстродействием в 2 мс , чем 2 слоя с быстродействием в 10 мс .
Цитата: Vertecs
А тормоза? Если перед обращением к памяти предупредить ОС о том, что есть намеренья обратиться к какой-то области, то тормозов не будет.
это вообще парадокс : давайте перед обращением к оси сообщим ей , что будем к ней обращатся . :)
это во первых , а во вторых : вы только подтверждаете мою догадку о вашем незнании предмета работы процессоров х86 в защищённом режиме .
Цитата: Vertecs
Если обратиться к сегменту, объявленным как байтовый массив, инструкцией DWORD-доступа, то прочтён будет только байт!
ещё одно подтверждение . почитайте лучше о страничной адресации , атрибутах страниц и проясните для себя как это работает .
Цитата: Vertecs
Как имено - это уже детали и вдаваться в них не буду:
ваша "ось" никому не нужна . голая идея ничего не стоит .
Цитата: koderAlex
это во первых , а во вторых : вы только подтверждаете мою догадку о вашем незнании предмета работы процессоров х86 в защищённом режиме .
Пока очень нетерпится ответить на это замечание... :D
Исключение сохраняет все сегментные регистры и РОН в памяти автоматически? По крайней мере из Зубкова я так понял.
Когда ОС возобновляет работу прерванного процесса, все регистры считываются из памяти полностью. Не ошибаюсь? Тут, да, тормоза большие.
Однако, если приложение получило от ОС сегмент к видео-области с 256-ю цветами, эта память всё ещё закрыта от приложения. Любой доступ к этим ячейкам непременно вызовет исключение. И что произойдёт в моей ОС? А вот что:
1) Чтение кода инструкции, вызвавшей исключение (для скорости работы ОС поддерживаются в основном строковые);
2) Если инструкция LODSD (например), то у неё D - не DWORD, а DATA. Т.е. опция обращения к памяти для ОС. Так-как графика в той памяти 8-битная, ОС непосредственно в памяти изменит только БАЙТ (!) в памяти, чтобы после возобновления работы у прерванного процесса изменился только AL, а EIP откорректируется на следующую инструкцию. Тем самым LODSD реальная не выполнит ся никогда;
3) Если инструкция LODSB, то B - не BYTE тоже, а тоже опциональная, например, BUFFER. Здесь ОС тоже будет задействовать совсем иные, свои механизмы;
4) А если инструкция SCASW? Ну, уж точно она не будет работать традиционно. Например, пусть W - тут будет не WORD, а WARP. А ОС, тем самым, переведёт координату EDI в перевычесленные координаты пространства SpaceWarp. А результат сохранить в ячейках, из которых будут восстановленны EAX и EDX...
Т.е. в этой ОС строковые инструкции ведут себя совсем не так, как должны. Каждая из них может менять своё поведение в регионах 2D-/3D-памяти, звуковых потоках. К примеру, в области аудио инструкция CMPSW может запустит сложный механизм опознавания речи и буквально вернуть код буквы, который произнесён, начиная с ESI-позиции.
Тормоза ещё какие! Но теперь мы знаем почему: CMPS/SCAS/LODS/STOS/MOVS(всего 15 * на /-/REP/REPNE, итого 45!) - не выполняются процессором, а интерпретируются самой ОС, вызывая порою достаточно сложные алгоритмы, требующие чудовищных вычислительных затрат. И в таком случае API-набор состоит всего из 45 функций. Причём, у видео памяти это 45 видео функций (ндя, SetPixel тут не место, слишком примитивная для интеллектуальных 45!);
У аудиосемплов это 45 звуковых функций (никаких Prepare и т.д.);
В сети это 45 сетевых функций (никаких OpenSocket)...
Тем самым, надеюсь, теперь Вы поняли, к чему я клоню? ;)