OSDev

Здравствуйте!
Долгое скитание по многим форумам меня здорово утомило.
Надеюсь найти здесь понимание и любую помощь.

Собственную ОСь задумал написать ещё в "дремучий" 1997 год.
Сейчас серъёзных наработок в этой области практически не имею, но желание - осталось.

Чтобы максимально упростить себе задачу, решил начинать писать ОСь не с начала, а с конца.
Т.е. написать некий менеджер - симулятор среды моей операционки. Менеджер задумал писать под Windows как виртуальный Floppy B: для начала. Так-как в Windows полнейщий пакет средств для графики, звука и прочей чепухи. Т.е. не надо будет писать с нуля драйверы под все устройства. Поэтому очень легко сосредоточиться на поставленной цели.

Итак, что должна из себя представлять plutOS вообще?
Когда-то у меня была мечта построить свой компьютер с нуля. Т.е. всю архитектуру разработать с самого нуля.
Поэтому, ОСь - некое подобие воображаемого компьютера. Я пытался как-то написать эмулятор этого компьютера. Т.е. программный эмулятор i8086 посадить в виртуальное аппаратное окружение. Но скорость работы меня сильно утомляла.
Но, зачем же программно переваривать код, если он аппаратно переваривается самим процессором? Поэтому я решил попытаться написать подобие VDM.
Тем самым, все реальные аппаратные порты эмулировать вообще не надо: у меня же задуман утопийный компьютер.
А теперь к делу!

Архитектура
Вместо 65536 портов ввода-вывода доступно все 4294967296, так-как при обработке исключения, вызванного командами in/out/ins/outs, очень легко вместо регистра dx учитывать весь edx.
Вместо 65536 значений сегментных регистров es/cs/ss/ds/fs/gs можно также обеспечить все 4294967296. Так, при исключении от команды mov es,ax обработать все биты eax! Получим 4294967296 сегментов по 4294967296 байт каждый! Гигантская виртуальная память.
Вместо стандартных динамических библиотек или хотя бы int-векторов на набор системных функций - ничего! Ведь задумывался именно виртуальный компьютер, а не ещё одна OS. Поэтому всё адресное пространство - девственно чисто. Все запускаемые приложения чувствуют себя как стандартный BIOS.
Железо такого компьютера тоже совершенно иное. Оно не просто какое-то специфическое, а реально - футуристически-интеллектуальное.

Общее представление
Итак, PlutOS - просто эмулятор нереального компьютера. Это уже выяснили. Поэтому, говорить о работе и особенностях этой ОСи просто бессмысленно. Так-как всё внимание нужно сосредоточить на описании самого этого нереального компьютера.
Первый принцип в том, что любое устройство в этом компьютере снабжено собственным мощнейщим процессором. От клавиатуры и мыши, до сетевой карты.
Значит, вместо того, чтобы предполагать наличие 4294967296 портов от различных загадочных устройств, мы будем иметь нечто иное. А именно...Ну и что здесь особенного? Можно подумать. Сейчас поясню.
Некоторые инструкции, как например, mov ees,eax и mov ees,[deviceId] на реальном железе никак не заставишь адекватно работать. Зачем же я замутил такое?
С другой стороны, допустим в моём этом нереальном компьютере всё же имеется своя BIOS, но в качестве псевдо-ОСи, лишь для перехвата подобных случаев с адекватной передачей параметров железу.
С этим, кажется, разобрались. Теперь про железо.
Здесь '/dev/keyboard' - клавиатура. По сегменту es появляется 4Гб ячеек нажимаемых клавиш!
С ума сойти? Разве может кто-нибудь за пару тактов процессора напечатать 4Гб и заполнить буфер? Конечно нет.
Клавиатура - виртуальная! Это аппаратно в IBM-PC клавиатура - один байт порта #96. У меня же клавиатура - что угодно. Хоть скачиваемая из интернета HTML-страница, хоть весь DVD-диск. Разницы, принципиально, никакой.
Как Вы теперь поняли, всё железо этого воображаемого компьютера - высокоуровневый ресурс. Поэтому надобность в стандартных библиотеках системных функций, со всякими sscanf/sprintf и т.д. просто отпадает.
Графический интерфейс тоже не набор массива пикселей, а HTML-документ или SVG-сцена.
Вот с OpenGL сложнее из-за отсутствия абстрактной формы описаний сцен. Поэтому можно использовать VRML.

Наброски
Как я уже сказал, эмулятор plutOS я решил выполнить как виртуальный Floppy B:. А не как Bochs скажем. Поэтому надо описать, как я это представляю.
После запуска эмулятора plutOS заходим в диск B: и видим там папку x32. Я не буду называть другие папки корневой директории, так-как смутно представляю ещё всю организацию. Там могут быть и папки x64, и даже z80! Для эмуляции ZX-Spectrum
Итак, зашли в B:\x32\ и видим там папку 00000001. Так plutOS нам предлагает индекс первого возможного процесса. Когда мы туда кинем файл процесса, появится папка 00000002 для второго. И т.д. Чтобы закрыть/убить процесс - просто удаляем любую из этих папок.
Теперь заходим в B:\x32\00000001 папку. Она пуста. Но мы можем её начать заполнять. Но строго нужно следить за именами создаваемых файлов. Причём, создавать в папке файлы просто так нельзя, так-как она подобна CD-приводу в XP, когда переносишь туда файлы перед прожигом. Копируются не файлы, а виртуальные линки на них.
Каждый файл в папке будет означать реально сегмент в процессе с тем же индексом. Если файл 12345678.bin, то в процессе это сегмент 0x12345678 и т.п.
Кроме того, необходим описательный файл к каждому сегментному. Так, в приведённом выше примере с клавиатурой это будет 76543210.bin и к нему 76543210.inf. В этом inf-файле, как в обыкновенном inf Windows в текстовом редактируемом формате мы найдём строчку '/dev/keyboard' и другу служебную информацию. Например, ссылку на реальный источник. Ага! Тут какрас и можем прописать 'con' или 'http://osdev.ru/'
Удаляем файл - грохается и сам сегмент в процессе.

Стандарты
Я не решился разрабатывать новые собственные форматы исполняемых файлов и их заголовки. Я поступил проще.
Берём де-факто tar или tgz и пакуем туда все bin'ы inf'ы нашего процесса. И получаем реальный экзешник plutOS!
Причём, если мы перенесли в папку B:\x32\00000001 наш HelloWorld.tgz, симулятор plutOS его распакует и мы увидим кучу bin'ов и inf'ов. После закрытия процесса все файлы будут удалены и папка отчистится, готовая к новому процессу.
Если же мы перенесём HelloWorld.tar, симулятор его распакует, как в случае с tgz. Но по завершению процесса все новые данные будут сохранены в оригинальный tar! Тем самым, tar-экзешники, в отличии от tgz, могут "развиваться"

Мультимедия
Конечно, симулятор plutOS должен поддерживать и mp3, и avi, и могое другое.
Если мы тупо перенесём в папку процесса avi-файл, plutOS сам сгенерирует bin и inf сегмента. А процессу будет отправлено событие о внедрении нового устройства.
Самое интересное то, что все 4Гб исходного сегмента под avi будет занято автоматически декодированным готовым первым кадром! Никакой декомпрессией процесс заниматься не должен.
Кадры всегда будут начинаться с es:[0]. А вот чтобы переключиться на n-ый кадр, нужно уже с помощью lock-префикса изменить служебные ячейки с индексатором кадра (напомню, служебные - значит в inf-файле).
Таким образом, без каких-либо библиотек с хитрым набором функций, процесс всего из пары десятков команд может воспроизвести даже видео напрямую с youtube!

Сценарии
Однако, не стоит думать, что я задумал plutOS так легкомысленно, что процесс воспроизведёт любой файл просто так. Я, всё-таки, программист, и понимаю, что здесь скрыт целый курган подводных камней.
Если говорить более детально, то для воспроизведения avi-потока нужно сначала настроить кучу сегментов на разные устройства. А именно.
Сначала настраиваем сегмент сепарации avi на два потока - видео и аудио. Чтобы система автоматически передавала поток из сегмента с avi в сегмента сепарации, нужно выполнить нечто похожее на lock movsb [edi],fs:[esi], когда es и fs указывают на сепаратор и на avi соответствнно.
Затем извлечённый поток аудио (mp3) нужно таким же образом направить из сегмента сепаратора в сегмент Huffman-декодера. Затем от него - в Фурье-синтезатор. И т.д. до получения распакованного wav, который уже перенаправится в проигрыватель потока, после чего реально появится звук!
То же самое нужно проделать и с видео данными, перенаправляя их от сепаратора к декодерам и фильтрам.
В результате, сам файл процесса вырастит ещё на сотню операций сборки этого конвеера! Чего можно избежать, если вручную набить все ступени самому прямо блокнотом в inf'ы.

P.S.: Если я всё достаточно хорошо изложил, суть plutOS уже более-менее ясна.
Знакомые мне сказали, что весь этот цирк с сегментами можно организовать в собственной сборке Linux. Подключив весь набор драйверов, кодеков и т.д.
А вот в Windows подобное организовать гораздо тяжелее на порядок!
К тому же, plutOS всё же задумывается и как самостоятельная ОСь где-то в далёкой перспективе. Пусть даже как ещё один дистрибьютив Linux.
Главнейщий минус ОСи - огромные тормоза из-за свистопляски с сегментами и кучей исключений.
Однако, этот минус я максимально стараюсь свести к минимуму с помощью сегментных lock-сценариев. Как Вы уже поняли.
Поэтому при чтении конечного сегмента, plutOS сама произведёт все трансформации от исходного файла до распаковки в отображаемый кадр.

Если у Вас есть какие-то документации на эту тему или Вы можете хотя бы час в неделю уделять времени на этот проект, очень буду рад любой помощи!
В моём профайле есть ссылка на мою страничку проекта.

Спасибо за внимание!

Зачем вам очередь для клавиатуры? Зачем сегментные регистры?
В защищённом режиме я не пользуюсь сегментами, а при работе с устройствами я не использую команды in, out, только mov.
Вы пишите на асме?
И ещё вопрос, как часто у вас переборы устройств?

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

Так-с, отвечаю по-порядку...
Я, кажется, всё подробно расписал.
Повторяю, что эта ОСь - подобие виртуального компьютера. Отсюда и порты, и сегменты.
Причём её необычность в том, что любые высокоуровневые операции выполняются простой манипуляцией сс сегментами x86-командами.
Пишу на си с _asm врезками.
Видеорежима нету. Вывод картинок, линий и текста - через html/svg.
Она, если честно, худшая из всех ОСей, как обзывали её на десятках других форумах. Достоинство одно - такого ещё не реализовывали, как я понял.
На рядовых пользователей она не расчитана, как и MenuetOS и KolibriOS. Просто на любителя, разбирающегося в ассемблере.
Все приложения - подобны BIOS'у: Запускаются в голом пространстве (повторяюсь)...

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

В данный период у меня проблема в следующем:
1. Выделить память под процесс (все 4Гб! Я же сказал, никакого API);
2. Оформить процесс, получить доступ ко всем его таблицам и дескрипторам;
3. CS регистр установить на 0xFFFF и EIP регистр обнулить (имитация сброса процессора);
4. Память CS:[0x00000000..0x0000FFFF] сделать отражением бинарника my_bios.x32 с моим кодом;
5. DS регистр обнулить и все 4Гб под него сделать отражением my_image.bmp;
6. ES регистр загрузить значением 0x0001 и все 4Гб под него сделать отражением my_table.bit;
7. Запустить процесс на отладку;
8. Обрабатывать все исключения. В частности, отловить команду rep movsb и обработать как вызов функции BitBlt;
Вот и всё на данном этапе. Код my_bios.x32 для начала не хитрый:

Затем надо:
9. Оформить диск B: как виртуальное пространство ОСи. Имитировать файловую систему, реагировать на добавление/удаление файлов. Развязать проблему шаринга, чтобы HIEW мог открыть-редактировать-сохранить любой и файлов. При этом все изменения должны сразу отражаться в тех сегментах.

В общем, работы уйма. А я застрял на пунтах 1, 2 и 3: Нельзя выделить 4Гб и изменять любой сегментный регистр. Система жутко ругается!
Не говоря уже про остальные пункты.

Сколько ни гуглю, ответ не найду...

Выделить память под процесс (все 4Гб! Я же сказал, никакого API);

Как вариант перейти в защищённый режим и загрузить такую таблицу
GDT:
NULL_descr db 8 dup(0)
CODE_descr db 0FFh,0FFh,00h,00h,00h,10011010b,11001111b,00h

Но в защищённом режиме нету ни каких функций не от Винды не от биоса.
Ну вы представте,что у вас есть мнимый ПК, а на нём мнимая ОС, и всё готово.

Я читал... И загрузчик писал... И GDT играл...
Не благоданое дело. Работаешь как в пустыне.
Поэтому, подчёркиваю, сейчас работаю только над симулятором под ВиндовсВ винде я и так в защищённом режимеЗачем смеётесь?

Ну если вы пользуетесь всеми функциями винды, то зачем вам регистры, там пишется просто, например PlaySaund(файл), темболее если на С+.
Если вы пишете для мнимой архитектуры со своими мнимыми контроллерами и не хотите для них писать драйвера(было бы странно обратное).
А как вы перенесёте систему если напишите на собственную сборку Linux, если такого ПК ни когда не будет.

Если пишеш ОС то пиши всё заново или дорабатывай существующие, тут к сожелению вариантов больше нету как мне кажется. Доработать Linux как я понял вы не стремитесь.
А лучше взять одну тему для разработки, и попытаться зделать её хорошо и помочь с ней другим.

При создании современной ОС сейчас даже на асм встретиш команды in, out только при чтении PCI, даже програмирование прерываний сейчас через APIC у которого все регистры в памяти, устройства все размещают регистра в памяти. Сегментные регистры тоде встретиш только в самом начале, при писании загрузчика, потом про них забываеш.
ОС это небольшая общая часть и куча реализаций отдельных частей, которые объединяются в общую систему.
Займитесь реализацией какой нибудь части. Общая часть ни кого не интересует, т.к. она у всех своя и помощи здесь не дождёшся, это только ваша фишка, которую вы должны сделать без чьеё либо помощи(иначе она уже станет не вашей).
В реализации частей у вас в помощ будут спецификации от интел, книжки и статьи. Книги все старые, новых не найдёте, статьи тоже. Спецификаций новых ни кто не открывает, кроме интел.

Если системным программированием никогда не занимались, то о разработке собственной архитектуры лучше не думать в серьёз. Мысли об этом могут быть после разбора сущетвующих технологий.

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

Это всё конечно хорошо, только врятли выльется в что-либо работающее с премлимой скоростью.
1) В Windows приложению (эмулятору компьютера) доступно 2 ГБ виртаульной памяти. Вы же хотите каждому устройству и процессу предоставить 4 ГБ "реальной", которая, разумеется, тоже виртуальна. Следовательно, даже простой запуск нескольких процессов при наличии пары-тройки устройств заставит выгружать всё на диск. Скорость оперативки и всей системы уже упала до 20 мбайт/с (так вроде счас стандартные харды работают). А заставить виртуальное устройство использовать не 4 ГБ а меньше, исходя из Вашей концепции, компьютер не в праве и должен предоставлять максимум.
2) Винда (и линукс тоже кстати) не позволит так просто менять CS и EIP и играться с ними, как заблагорассудится. Как-никак, аппаратная защита. Таблица дескрипторов в винде есть, занесение неверного (а таких большинство; верными вообще являются не больше 256*4 для GDT и еще столько же для LDT) значения в тот же cs прибьет процесс. Значит, всю описанную работу с сегментными регистрами придется эмулировать на обычных регистрах. Как следствие, эмуляция всего остального, связанного с Вашей адресацией. Получаем падение скорости ещё раз в 10-50 (в зависимости от качества эмуляции).
3) Я так понял, в архитектуре не будет никаких защит, раз любой процесс может так просто взять и обратиться в любую ячейку памяти. Такой подход не позволит сделать мало-мальски USER-полезную ОС на таком компьютере, поскольку система будет падать по каждому чиху. Разве что запускать 100% проверенные приложения. И то, ошибка в любом опять же может свалить систему.
4) Аппаратная поддержка музыкальных и видео форматов на компьютере? Смысла никакого. Сегодня есть AVI и MP3, а на следующий день после выхода такого "утопийного" компьютера появился новый MP16 и AVI10, при этом для их воспроизведения на компьютере его придется менять на новый (если бы он был физическим объектом), или перекомпилировать и скачивать новый (весь! все N МБ/ГБ!). Представьте, если бы ради того, чтоб открыть файл нового формата, нужно было переставлять винду.

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

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

Хочу вкратце рассказать, как я пришёл к такой экзотической концепции. Хотя реально, я не за один вечер это придумал. На всё ушло целые годы.
Так, в одном из чатов в диалоге с другом мы обсуждали механизмы Windows. В частности, функция GetLastError в конечном итоге сводится к двум инструкциям процессора:

К тому же, в KolibriOS через gs сегмент организован доступ к памяти дисплея.
Тогда я подумал, а почему бы не сделать и другие механизмы так же?
Например, отказаться от функции чтения текущих даты/времени. И перенести все в fs. Я понимаю, что fs просто указывает на TIB и 0x34 - смещение в структуре. Не надо стараться меня поймать на этой чепухе.
Просто можно было бы расширить применение и ввести переменные даты и времени.
Когда управление получает ядро, перед переключением на следующий процесс заранее обновляется и величина времени.

Потом, подобно KolibriOS, подумал перенести под gs все функции GDI. Но перенести несколько иначе. Так, gs указывает на структуру, где первые 65536 байтов - массив RGBA[16384] для графической строки окна.
Затем идут другие байты этой структуры, где указывается и HDC, и текущая строка контекста (Y), и DrawMode.
Работа задумывалась так. Сначала доступ к массиву RGBA закрыт и первое же обращение командой rep movsd вызовет исключение. Мой GDI-менеджер это поймает, глядя на rep movsd по eip поймёт, что в edi - X первого пиксела, в ecx - число пикселей, а в esi - массив RGBA. Он сам одним махом скопирует данные массива и выведет на поверхность окна. Потом возобновит работу того процесса, уже пропустив те rep movsd, заранее откорректировав ecx, esi и edi в нём.
Тем самым, вместо кучи исключений на каждый rep movsd с медленным переводом их в SetPixel, мой менеджер махом сам всё сделает за одно исключение.
Такие механизмы очевидны. Ежу понятно.
Если довести gs-структуру до ума, ввести помимо Y ещё и кординаты X1,Y1,X2,Y2, можно чертить не только горизонтальную линию на окне, но и по произвольному направлению. А надо будет, и в Bizier...
Можно бесконечно наворачивать этот менеджер и усложнять интерпретацию этих rep movsd, rep movsw, rep movsb, где ширина слова (d/w/b) может указывать не на ширину слова, а на любой опциональный режим.
Так шло развитие идеи.
Конечно, с помощью VirtualAlloc и обработчика исключений реализовать это было за один плевок в урну!
Но я увлёкся и идея росла как снежный ком без реализации, а лишь как концепция.

Второй шаг развития начался, когда я решил менеджер расширить от простого GDI до более продвинутой структуры. Вместо RGBA[16384] ввести кучу других действий. Например, mov edi,WINDOW_CAPTION ; rep movsb тупо интерпретируется в if(edi == WINDOW_CAPTION) SetWindowText(...esi...).
Тоже самое и со многими остальными функциями, замаскированными под исключение.
Потом я подумал, зачем вообще такая структура по gs? А если будет сбой указателя, он может попасть куда угодно!
Так я решил перевести всё в виртуальные порты. Так, mov edi,WINDOW_CAPTION ; rep outsb - всё тот же SetWindowText! Правда программировать нужно уже всё через _asm, а в си это не красиво. Та структура была куда гибче!
Тем более нужно писать свою кучу #define WINDOW_CAPTION 0x1234... И придумывать цифры с потолка.
Не красиво!

Третий шаг был глобальнее. А что если выделить не 64кб структуры по gs, а все 4Гб? Ведь все 4Гб - не виртуальные даже, а формальные. Т.е. ни в каком файле не будут занимать ни байта!мною нечто подобное делалось. Я тупо написал топором за сутки парсер байт-кода(ещё на моём первом тогда Pentium-90MHz 48Mb-RAM!), короче говоря, грубый эмулятор i80386 процессора как попало. Где подобный код работал с черепашьей скоростью. Но выводил OpenGL сферы и создавал в окне несколько кнопок. Главное, этот виртуальный топорный процессор работал и создавал иллюзию функционирования виртуального компьютера. Машина вполне тянула мой бред;

Практически, это три основных вопроса, которые я не могу решить:
1. Резервирование 4Гб памяти под тупое исключение на всём протяжении (по сегментам gs,fs,es);
2. Зарезервировать ещё 4Гб, но 64кб отдать под процесс (cs:eip=0x00000000..0x0000FFFF) сделав зеркалом файла на диске;
2. Повесить свой обработчик исключений над этим процессом.
Серъёзно никогда не занимался системный программированием и ума не приложу, как копать эти вопросы.

Спасибо за внимание!

У них к видео буферу через gs, у меня сегменты на используются, а просто адрес LFB как начало и добавляю смещение. Сегменты это чтото из 16битного, в 32битном у тебя линейный адрес на почти 4Гб и делай с ним что хош, без сегментов.

Я лично, пытаюсь избавиться от переборов, четвёртый байт пикселя использую как прямую ссылку на объект(номер в массиве объектов), чтобы не переберать все объекты и не проверять у всех принадлежность их области координате мыши плюс они могут быть друг за другом. А по движению мыши постоянно нужно спрашивать, какой объект под ней и какой там курсор(кстати в KolibriOS этого нету). У всех объектов делаю ссылки разные, на функции(благо в фасме есть команда jmp), короче пытаюсь ускорить процесс.
А вы зачем то замедляете, и драйвера не хотите писать, а здесь все занимаются этим как раз(оптимизация и аппаратная часть как не крути).

Займитесь аппоратной частью, это как раз то о чём вы говорите, это не так уж и сложно, спецификаций интел достаточно для написания современной Оси, там и диски и флешки, аудио, видео и даже многопроцессорность, и управление питанием, всё современное открыто и всё это размещено в оперативке и команды in out не нужны. Биос вам это всё при загрузки оформляет в виде регистров устройств в верхних адресах, вы их читаете у PCI и прыгаете по ним читая нужную вам инфу и посылая устройствам пакеты(сектор прочитать или файл воспроизвести). Устройства сейчас пакеты с адресами в память обрабатывают без использования процессора и не теряется производительность.

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