OSDev

Для объекта задача я создам поля:
1 Адрес каталога страниц реальный
2 Адрес каталога страниц виртуальный
3 Адрес объекта с кодом (сам код может находиться в системе или быть загружен в пространство задачи по любому адресу)
4 Адрес общего буфера в виртуальном пространстве системы (в пространстве задачи он будет на 8Мб)
5 Тип задачи(активность, присутствие: буфера, постоянного таймера, доступ: интернета, звука, дисков, периферии, .... .)
6 Функцию добавления памяти к задаче(добавление к задаче страниц памяти)
7 Функция освобождении памяти из задачи(освобождения страниц памяти)
8 Функция активации задачи (загрузка адреса каталога страниц)
9 Функция закрытия задачи (освобождении всех занимаемых ею страниц памяти)

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

В менеджере задач можно будет администрировать её возможности.
Кстати в этой не самой сложной модели можно насчитать несколько десятков плюсов по сравнении с существующими.

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

Зачем нужен виртуальный адрес каталога? Лучше, чтобы в структурах процесса/потока было по минимуму или вообще не было таки специфических полей, как адрес видеобуфера (к тому же зачем оно вообще нужно, если адрес общий). Конечно с задачами могут быть связаны специфичные версии общесистемных функций, но не нужно все системные функции делать специфичными для задачи.

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

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

Не понятно, что такое "система". Системный процесс? Ядро?

Зачем окну нужен "видеобуфер"? Ты что собираешься попиксельно хранить образ каждого окна? ...К тому же у задачи может быть много окон.

На самом деле все достаточно просто. Ты просто отображаешь видеобуфер в пространство каждой задачи, в пространство ядра (если хочешь закрыть прямой доступ к видеобуферу со стороны приложений) или в прикладное пространство (если закрывать прямой доступ к видеобуферу со стороны приложений не требуется).

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

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

Всю систему я пытаюсь делать без необходимости в непрерывной памяти.


Ядро это несколько страниц чистого кода, который дублируется в каждое виртуальное пространство, все переменные в объектах для которых выделяется память и регистрируются в главном объекте с постоянным адресом. Главный объект имеет поля для цепочек из объектов кодеков, задач, компонентов, протоколов, драйверов, окон, .... т.е. разбиты по тематике. В этом есть смысл, т.к. задача не должна содержать в себе драйвер или сетевой протокол, для безопасности, и если все будут свои кодеки и компоненты хранить в одном месте то ими могут воспользоваться и другие задачи.

Кстати все запущенные объекты должны быть также в общем дублируемом адресном пространстве, т.к. их адреса должны быть доступны по движении по ним мышки на экране при их присутствии на нём в любой форме.

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

Это он переизобретает композитинг (http://en.wikipedia.org/wiki/Compositing_window_manager).
Не совсем в тему, но "Those who cannot remember the past are condemned to repeat it" (ну и с вариациями этой пословицы).

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

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

Ну так, вроде, сам на свой вопрос и ответил.